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Marine  Corps  Addendum  to 
the 

JSIMS  ORD 

1.  General  Description  of  Operational  Capability 
(see  Joint  ORD) 

2.  Threat:  Not  Applicable 

3.  Shortcomings  of  Existing  Systems 

The  current  constructive  simulations  used  for  training  in  the  Marine  Corps  are  primarily  the 
MAGTF  Tactical  Warfare  Simulation  (MTWS)  and  to  support  high  resolution  requirements  the 
Joint  Tactical  Simulation  (JTS)  and  the  Joint  Conflict  Model  (JCM).  MTWS  was  designed  to 
support  Marine  Corps  commander  and  staffs.  MTWS  is  also  a  member  of  the  Joint  Training 
Confederation  of  simulations.  The  JTC  allows  limited  communication  between  the  simulations 
via  the  Aggregate  Level  Simulation  Protocol.  Due  to  this  limit  Marine  Corps  warfighting 
capabilities  are  inadequately  represented  in  the  JTC.  For  high  resolution  exercises  the  MTWS 
does  not  represent  events  as  well  as  the  JTC.  However,  MTWS  and  JTS  do  not  have  an  interface 
with  each  other.  Only  JTS  with  its  Distributed  Interactive  Simulation  protocol  would  be  able  to 
provide  a  synthetic  environment  to  virtual  simulators  and  live  instrumented  ranges  and  units. 
Neither  simulation  has  an  interface  to  Marine  Corps  C4I  systems  and  both  require  significant 
effort  to  build  scenario  databases  and  exercise  overhead  in  terms  of  controller  and  response  cell 
workload. 

4.  Capabilities  Required 

System  Performance 

4.1.1  General.  In  supporting  a  tactical  exercise,  the  JSIMS  must  accept,  store,  process, 
generate,  and  display  comprehensive  data  on  the  simulated  operations  of  the  modeled  forces. 
The  System  must  accept  data  input  by  terminal  operators  using  keyboards,  pointing  devices,  and 
voice.  Data  which  must  be  retained  for  later  access  must  be  stored  on  mass  storage,  magnetic 
media.  Data  processing  and  information  generation  must  be  performed  to  provide  controllers 
and  players  with  continuously  updated  information  for  centralized,  near-real-time  control  of 
exercise  play.  This  information  must  take  the  form  of  advisory,  cautionary,  and  status  tabular 
displays  as  well  as  graphic  displays  portraying  the  current  tactical  situation. 

4. 1 .2  The  data  must  be  stored  for  retrieval  as  needed  during  the  exercise  and  for  after  action 
review. 
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1.  Program  Definition  and  System  Overview 

National  Air  and  Space  (Warfare)  Model  (NASM)  will  be  a  distributed  simulation  system 
that  provides  an  air/space  joint  synthetic  battlespace  that  will  meet  the  operational  needs 
of  the  USAF.  NASM  will  provide  the  functional  capability  to  realistically  represent  the 
full  range  of  aerospace  power  applications  (including  supporting  functionalities  such  as, 
logistics,  intelligence,  medical,  engineering,  communication,  geophysical, 
meteorological,  oceanographic,  space,  environmental  factors,  and  information  warfare) 
for  both  Air  Force  specific  and  joint  training. 

NASM  will  provide  an  operationally  realistic,  distributed,  simulated  mission  space  that 
includes  a  synthetic  environment,  force  representation,  and  behavioral  representation. 
NASM  will  be  used  by  commanders  and  battlestaffs  (from  wing  level  up  to  and  including 
Joint  Force  Air  Component  Commander  (JFACC)),  and  other  organizations  as  needed  to 
support  global,  theater,  regional  training  and  readiness  exercises;  education  and  seminar 
training;  development  of  doctrine  and  practice  of  operational  art;  situation  assessment; 
and  the  formulation,  assessment;  and  rehearsal  of  operational  plans.  NASM  shall  support 
training  exercises  over  extended  geographical  distances. 

NASM  will  interface  with  real  world  Command,  Control,  Communications,  Computers, 
and  Intelligence  (C4I),  and  support  systems  to  provide  resource  efficient  and  intuitive 
interfaces  for  training  execution  in  the  places  these  operations  would  normally  be 
conducted.  The  NASM  domain  will  include  the  full  spectrum  of  air  and  space  operations 
(including  Force  Application  (Strategic  Attack,  Interdiction,  Close  Air  Support  (CAS)); 
Aerospace  Control  (Defensive  Counterair  (DCA),  Suppression  of  Enemy  Air  Defense 
(SEAD),  (Offensive  Counter  Air  (OCA));  Situation  Assessment/C3I  (Battle 
Management,  Communication,  Reconnaissance,  Intel);  Mobility  (Airlift,  Refueling), 
military  operations  other  than  war  (MOOTW),  information  warfare,  and  special 
operations.  NASM  will  be  flexible  and  extensible  to  incorporate  additional  functionality 
and  evolve  to  address  additional  modeling  user  communities,  (e.g.,  analysis,  test  & 
evaluation,  acquisition)  and  operational  needs,  (e.g.,  decision  support,  tactics  trials). 

NASM  will  be  developed,  deployed,  operated,  and  maintained  in  a  cost  effective  and 
efficient  manner.  To  provide  a  maintainable  system  with  a  evolutionary  life-cycle, 
NASM  will  be  developed  using  modem  computer  technologies,  software  engineering, 
open  system  interfaces,  and  will  maximize  the  use  of  off-the-shelf  hardware,  software, 
validated  algorithms,  and  real  world  databases. 


1.1  System  Description  and  Architecture 

The  joint  synthetic  battlespace  is  an  operationally  realistic,  distributed,  simulated  mission 
space  that  includes  a  synthetic  environment,  force  representation,  and  behavioral 
representation.  NASM  represents  those  objects  which  are  specifically  USAF  assets,  as 
well  as  those  areas  of  interest  in  which  those  assets  may  interact  (e.g.,  OPFOR,  neutrals, 
ground  targets,  infrastructure  for  information  operations,  et  al). 
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The  NASM  architecture  will  be  a  flexible  framework  that  will  integrate  representations  of 
the  various  missions  of  the  Air  Force.  This  NASM  framework  will  consist  of  a 
distributed,  discrete  event,  constructive  simulation  with  the  capability  to  interact  with 
virtual  and  live  simulations  and  simulators.  The  NASM  framework  will  support  multiple 
levels  of  resolution  in  accordance  with  user  needs.  It  will  be  developed  in  conjunction 
with  other  major  programs  addressing  simulation  components  and  standards. 

The  NASM  system  will  be  based  upon  an  open  system  architecture,  non-proprietary 
software,  higher  order  programming  languages,  and  off-the-shelf  software  and  hardware. 
The  NASM  system  will  be  capable  of  executing  as  a  standalone  simulation  or  as  part  of  a 
federated  simulation  system.  NASM  will  have  the  ability  to  interface  with  real  world  C4I 
interfaces  (simulated  or  live). 

NASM  will  be  a  next  generation  distributed  discrete  event,  object  oriented,  composable 
simulation  system.  The  NASM  system  will  embrace  a  number  of  architectural  principles: 

•  NASM  will  comply  with  the  DoD  Modeling  and  Simulation  High  Level 
Architecture  (HLA).  Where  technically  feasible,  NASM  will  comply  with  the 
HLA  internally,  although  this  only  refers  to  interface  specifications  as  opposed  to 
reuse  of  reference  RTI  implementations. 

•  NASM  will  be  consistent  with  objects  described  by  the  Federation  Object  Model 
(FOM). 

•  NASM  objects  will  use  HLA  Run  Time  Infrastructure  (RTI)  services  for 
coordination  with  other  simulations  and  transfer  of  data. 

•  NASM  entity  representation  range  from  sub-components  to  aggregate  units. 
Entities  will  have  discrete  behaviors  (not  simply  the  aggregation  of  component 
behaviors) 

NASM  provides  for  fully  automated  computer  generated  forces  (CGFs),  semi-automated 
forces  (SAFORs),  command  center  and  warfighter-in-loop  (WITL)  forces  at  any  echelon 
in  any  permutation  for  multiple  sides.  Depending  upon  the  exercise,  NASM  could  run 
from  fully  automated  to  fully  manned. 

The  NASM  system  will  provide  several  different  environments  to  be  used  in  each  of  the 
phases  of  a  NASM  exercise.  The  pre-exercise  environment  will  be  used  by  the  training 
staff  during  the  exercise  preparation  to  do  planning  and  setup  of  the  exercise.  The 
Execution  Environment  will  be  used  by  the  training  staff,  the  exercise  controllers,  and  the 
trainees  during  the  running  of  the  exercise.  The  post-exercise  environment  will  be  used 
by  the  training  staff  for  exercise  review,  which  will  take  place  both  during  the  running  of 
the  exercise  execution  and  in  post-exercise  analysis. 


-5- 


Version  7.3, 19  Mar 


96 

Draft  National  Air  &  Space  [Warfare]  Model  (NASM)  Technical  Requirements  Document 

1.2  Components 

NASM  will  allow  the  interoperability  of  object-based  software  components  in  distributed 
heterogeneous  environments.  Intra-simulation  interoperability  must  be  at  least  as  flexible 
as  the  Object  Management  Group's  (OMG)  Object  Management  Architecture  (OMA) 
Reference  Model.  NASM  will  allow  multiple  component  systems  to  be  run  on  the  same 
computing  platform  and  a  single  system's  components  to  be  distributed  amongst  many 
geographically  dispersed  computing  platforms.  NASM  will  provide  common  facilities 
and  services  where  usable  by  more  than  one  group  of  objects. 


1.2.1  Objects 

NASM  will  provide  a  common  object  format  for  intra-simulation  interoperability  using  a 
robust  and  reliable  (assured)  distributed  object  message/interaction  protocol. 

Mechanisms  will  be  provided  for  distributed  object  visibility  triggers  to  reduce  wide  area 
network  traffic.  The  object  format  will  provide  a  consistent  interface  for  inter-simulation 
interoperability  (e.g.,  within  JSIMS). 


1.2.2  Common  Facilities 

NASM  will  provide  common  facilities  comprised  of  tools  and  reusable  shared  software 
components  for  use  by  service  objects  and  models.  The  common  facilities  contain  the 
agreed-to  representations  of  how  USAF  forces  operate.  These  representations  are 
contained  in  structures  such  as  class  libraries,  data  bases,  and  object  repositories.  These 
facilities  will  include  environmental,  force,  support,  simulation  management,  and  activity 
model  components. 


1.2.3  Common  Services 

NASM  will  provide  common  services  comprised  of  tools  and  reusable  shared  software 
components  for  use  by  service  objects  and  models.  Services  will  be  products  that  range 
from  low-level  system  utilities  to  higher-level  applications,  such  as  database 
management.  Common  Services  will  be  comprised  of  components  which  meet 
Government  and  industry  standards  promoting  open  architecture  in  a  multiple  vendor 
heterogeneous  environment.  These  services  include  such  components  as:  network 
services,  graphics,  security,  operating  systems,  documentation,  instrumentation,  system 
management,  distributed  computing  environment,  knowledge  servers,  and  other  services. 
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1.2.4  Application  Tools 

Application  tools  will  be  developed,  including  scenario  generation,  simulation  controls, 
system  control,  archive  utilities,  and  others.  All  NASM  application  tools  will  meet  the 
technical  goals  of  the  NASM  framework. 

The  NASM  Architecture  will  include  tool  frameworks  which  will  specify  the  required 
interface  between  applications  and  the  architecture  to  achieve  reliable,  portable  operation 
in  a  distributed  environment. 


1.3  Requirements  Baseline 

As  the  NASM  system  is  developed,  changes  to  the  system  and  requirements  are 
anticipated.  This  TRD  describes  all  currently  known  requirements  and  provides  insights 
into  the  NASM  “growth”  areas.  To  establish  an  initial  baseline  for  each  external 
interface  system,  the  latest  version  of  the  system’s  ICD  and  external  system  software  will 
be  used  at  the  onset  of  the  NASM  system  development.  The  external  system  software 
will  prevail  when  there  is  a  discrepancy  between  the  ICD  and  the  software.  The  NASM 
system  must  be  flexible  so  that  changes  to  the  external  system  interfaces  may  be 
incorporated  to  provide  interoperability  with  releases/upgrades  of  identified  and  new 
external  systems. 


1.4  Document  Overview 

This  document  establishes  the  functional  and  performance  requirements  for  NASM.  This 
document  also  provides  technical  guidance  for  NASM.  The  requirements  and  guidance 
within  this  document  describe  initial  operational  capabilities  (IOC)  required,  the  initial 
sites  where  NASM  will  be  fielded,  and  full  operational  capabilities  (FOC)  and  additional 
sites  where  NASM  will  be  fielded.  The  NASM  system  as  described  can  be:  standalone  to 
support  Air  Force  training  exercises  or  educational  seminars;  or  integrated  with  larger 
simulation  systems  such  as,  JSIMS,  to  support  joint  training  exercises. 

Section  1  of  this  document  provides  a  system  overview.  Section  2  contains  a  list  of 
references.  Section  3  describes  the  system  capabilities  to  be  provided  by  the  NASM 
system.  This  document  provides  the  Government’s  current  understanding  of  NASM  and 
its  evolution.  Section  3  does  not  provide  a  detailed  set  of  requirements;  rather  a  high 
level  set  of  functional  and  performance  requirements  that  will  be  used  as  the  basis  for  the 
NASM  system  specification.  Within  section  3  all  requirements  are  denoted  with  a 
“shall”.  A  “will”  or  “must” denotes  a  goal  and  provides  more  information  related  to  a 
system  requirement  and  system  objectives.  Sections  4  and  5  are  not  applicable.  Section 
6  provides  a  notes  that  present  the  reader  with  some  design  and  implementation 
considerations.  Section  6  is  non-binding  and  intended  for  information  purposes  only.  The 


-7- 


Version  7.3, 19  Mar 


96 

Draft  National  Air  &  Space  [Warfare]  Model  (NASM)  Technical  Requirements  Document 

Appendices  contain  a  glossary,  a  functional  description  of  IOC/FOC  capabilities,  and  an 
acronym  list. 

2.  Applicable  Documents 

2.1  Government  Documents 


2.1.1  Specifications 

DMSO  Department  of  Defense  (DOD)  High  Level  Architecture  (HLA)  for 
Simulations,  Interface  Specification,  Version  0.4,  dated  7  March  1996 


2.1.2  Standards 

DOD  Technical  Architecture  Framework  for  Information  Management  (TAFIM), 
Air  Force  Technical  Reference  Codes  (TRC) 

DOD  Technical  Architecture  Framework  for  Information  Management  (TAFIM), 
Reference  Models  and  Standards  Profile,  Version  2.0,  dated  1  November  1993 

2.1.3  Other  Publications  (Reference  Only) 

Air  Force  Manual  1-1,  Basic  Aerospace  Doctrine  of  the  United  States  Air  Force, 
Volumes  I  and  II,  dated  March  1992 

Air  Operations  Center,  ACCI 13-150  (draft),  dated  26  October  93  (draft) 

CACI  Prototype  Architecture  Specifications,  Rev.  02.1,  dated  5  January  1995 

CACI  Protoype  Final  Process  Redesign  Plan,  29  September  1995  (CACI 
prototype  document) 

CACI  Prototype  Software  Requirements  Specification  for  NASM,  dated  12 
December  1995 

DMSO  DOD  High  Level  Architecture  (HLA)  Management  Plan,  dated  17  July 
1995 
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DMSO  DOD  High  Level  Architecture  (HLA)  Object  Model  Template,  dated  17 
July  1995 

System  Design  Document  for  AWSIM/R,  TRN  1 1,  dated  8  September  1995 

System  Specification  for  AWSIM/R,  TRN  11,  date  28  July  1995 

USAF  Air  Force  Doctrine  Document  (AFDD)  1,  Air  Force  Basic  Doctrine,  dated 
15  August  1995,  First  Draft 

USAF  Air  Force  Doctrine  Document  (AFDD)  3,  Military  Operations  Other  than 
War,  dated  5  December  1995,  Proposed  Final  Draft 

USAF  Air  Force  Doctrine  Document  (AFDD)  35,  Special  Operations,  dated  16 
January  1995 

USAF  Air  Force  Doctrine  Document  (AFDD)  5  Information  Warfare,  Preliminary 
Draft,  dated  xx,  1995 

Warrior  Preparation  Center  Planning  Conference  Workbook,  dated  April  1994 

2.2  Non-Government  Documents 
TBD. 

2.2.1  Specifications 

TBD. 

2.2.2  Standards 

TBD. 

2.2.3  Other  Publications 

TBD. 
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3.  System  Requirements 

NASM  shall  provide  an  operationally  realistic,  distributed,  simulated  mission  space  that 
includes  a  synthetic  environment,  force  representation,  and  behavioral  representation. 
NASM  will  be  used  by  commanders  and  battlestaffs  (from  wing  up  to  and  including  Joint 
Force  Air  Component  Commander  (JFACC)),  and  other  organizations  as  needed  to 
support  global,  theater,  regional  training  and  readiness  exercises,  education  and  seminar 
training,  development  of  doctrine  and  practice  of  operational  art,  situation  assessment, 
and  the  formulation,  assessment,  rehearsal  of  operational  plans.  NASM  shall  support 
training  exercises  distributed  over  extended  geographical  distances  using  wide-area 
networking  (WAN)  technologies. 


3.1  Types  of  Users 

NASM  shall  provide  a  simulation  system  framework  adaptable  to  many  modeling  and 
simulation  applications.  NASM  shall  have  three  classes  of  users  —  end  users  (e.g., 
battlestaffs  receiving  training  or  students  playing  wargames  during  educational  seminars), 
technical  controllers  (those  who  set  up  and  run  the  simulations),  and 
developer/maintainers. 


3.1.1  End  Users 

NASM  shall  initially  focus  on  the  operational  readiness  environment  at  the  campaign 
level,  addressing  the  complete  USAF  operational  environment,  including  USAF 
commanders  and  battlestaffs  (up  to  and  including  Joint  Forces  Air  Component 
Commanders  (JFACCs)),  and  related  mission  organizations.  NASM  shall  provide  the 
capability  to  conduct  training  for  battlestaffs  at  the  AOC  down  to  (and  including)  the 
wing  level  (with  or  without  participation  by  higher  and  collateral  level  staffs)  through 
improved  simulation  of  agencies  external  to  the  battlestaff  being  trained.  Conversely, 
when  lower  levels  are  not  represented  as  player  elements  in  an  exercise,  NASM  shall 
have  the  capability  to  realistically  portray  their  presence  to  the  higher  level  staffs.  See 
Figure  3-1. 


Figure  3-1.  Simulation  System  Participants 


3.1.1. 1  NASM  shall  also  focus  on  the  educational  community  requirements.  The 
educational  audience  plays  the  roles  of  a  theater  CINC,  supporting  air,  ground,  and 
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sea  component  commanders  and  their  supporting  staffs.  Seminars  of  students 
consist  of  active,  reservesk  and  civilian  force  and  have  varied  speciality  areas. 
Approximately  only  30  percent  of  the  students  have  an  operational  background. 

3.1.2  Technical  Controllers 

NASM  will  provide  the  capability  to  incrementally  automate  many  of  the  manpower 
intensive  control  functions  typical  to  existing  simulations  throughout  the  exercise  time 
frame  -  planning,  scenario  generation  (intelligent  laydown  of  friendly  and  opposing 
forces),  execution  (knowledge-based  system  order  validation),  post-processing  analysis, 
and  after-action  reviews.  NASM  technical  controllers  shall  have  the  ability  to  start, 
freeze,  stop,  restart,  rollback,  shutdown,  save  the  state  of  all  data  in  the  system,  record 
selected  events,  select  the  time-step  in  which  to  operate,  and  control  system  configuration 
(i.e.,  distributed,  single  site).  NASM  technical  controllers  shall  have  the  ability  to: 

a.  initiate  an  exercise,  control  the  exercise  via  exercise  parameters,  interject  events, 
and  monitor  the  exercise  and  its  results; 

b.  define  (during  pre-simulation)  and  adjust  (during  simulation  system  execution)  all 
scenario  elements  and  wargame  conditions,  including  definition  of  sides  and 
responsibilities  in  support  of  an  exercise; 

d.  end  the  exercise.  Ending  the  exercise  will  not  allow  the  exercise  to  be  restarted. 
However,  an  exercise  can  be  restarted  within  10  minutes  from  a  saved  checkpoint 
or  the  exercise  may  be  played  back  for  debriefing  purposes; 

d.  pause  and  resume  the  exercise; 

e.  initiate  checkpoint/state  save; 

f.  select  After  Action  Review  (AAR)  and  mission  report  data  to  be  collected  and 
stored  during  an  exercise; 

g.  select  data  and  reports  to  be  generated  and  printed  before,  during,  and  after  the 
simulation  execution; 

h.  define  and  store  user  defined  report  formats; 

i.  set  and  change  the  logical  time  scale  and  absolute  exercise  time  during  the 
exercise; 

j.  support  the  full  range  of  all  service/branch  coordinate  systems; 
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k.  manage  the  range  of  interface  objects,  devices,  and  systems,  including  the  user 
views  for  each  side  (allied,  opposing,  neutral,  unknown,  etc.)  of  the  game; 

l.  change  the  status  of  the  simulated  entities.  For  example,  controllers  may  have  the 
ability  to  relocate  units,  resupply  units,  restore  equipment,  disable  equipment, 
change  the  damage  status  of  roads,  bridges,  airfields,  etc.; 

m.  insert  events  and  activities  related  to  information  warfare; 

n.  allow  the  centralized  management  of  up  to  a  minimum  of  44  independent, 
simultaneous,  executions  of  simulation(s). 

The  number  of  technical  controllers  required  to  support  an  exercise  will  vary  depending 
upon  the  exercise  and  training  objectives;  however,  the  number  of  technical  controllers 
shall  not  exceed  5  per  exercise  node  during  simulation  execution.  (Exercise  node  refers 
to  a  physical  geographic  location.  However,  it  is  possible  that  one  facilty  may  model 
multiple  geographic  locations  (exercise  nodes)  for  the  purposes  of  training.) 


3.1.3  Developer/Maintainers 

NASM  shall  establish  a  development  architecture  that  consists  of  automated  support  tools 
to  facilitate  wide-spread,  cooperative  development  of  simulations  using  a  common  design 
implementation  methodology.  The  development  architecture  shall  provide  common 
development  facilities  to  permit  multiple-resolution  representations  of  entities  and 
environments  to  facilitate  flexible,  extensible,  and  consistent  use  of  simulations. 

3.1.4  Additional  User  Communities 

NASM  shall  be  flexible  and  extensible  to  incorporate  additional  functionality  and  evolve 
to  address  additional  modeling  user  communities,  (e.g.,  analysis,  test  &  evaluation, 
acquisition)  and  operational  needs,  (e.g.,  decision  support).  The  initial  design  shall  be 
sufficiently  flexible  to  accommodate  these  expanded  requirements,  shall  ensure  that 
objects,  data  and  algorithms  employed  are  consistent  with  documented  or  commonly 
accepted  standards  used  in  these  communities;  and  shall  provide  an  architecture  and 
connectivity  for  collecting  and  organizing  simulation  outcomes  and  their  underlying 
event  and  input  data. 

3.2  Functional  Requirements 

The  NASM  system  shall  provide  simulation  capabilities  for  pre-exercise,  exercise 
execution,  and  post  exercise  analysis  in  the  simulation  system  use  exercise  lifecycle.  See 
Figure  3-2. 
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Figure  3-2.  Functional  View  of  NASM 


3.2.1  Pre-Exercise 

The  pre-exercise  functionality  shall  provide  a  distributed/collaborative  planning,  user 
friendly  means  for  the  NASM  technical  controllers  to  generate  scenarios  and  support 
exercise  preparation. 

3.2.1. 1  Scenario  Generation 

The  NASM  system  shall  provide  a  collaborative  scenario  generation  subsystem  that 
allows  the  users  to  create,  modify,  delete,  copy,  merge,  store  and  catalog  scenarios  over 
geographic  dispersed  sites.  A  minimum  of  3  technical  controllers  shall  be  able  to 
concurrently  develop  the  same  scenario.  The  NASM  scenario  generation  subsystem 
shall  provide  an  audit  log  to  track  the  changes  made  to  the  scenarios  during  the  scenario 
generation  process. 

Exercise  scenario  generation  shall  provide  the  capability  to  define  scenarios  to  support 
the  missions  defined  in  section  3.3  of  this  TRD.  Exercise  scenario  generation  shall 
provide  the  capability  to  create/establish  the  initial  scenario  elements  and  wargame 
conditions.  The  process  of  creating  a  scenario  shall  be  automated  to  the  maximum  extent 
feasible,  including  automating  the  process  of  obtaining  data  from  external  real  world  C4I 
systems,  and  other  sources  of  scenario  data  such  as,  Defense  Intelligence  Agency’s 
(DIA’s)  Multi-Spectral  Force  Deployment  (MSFD)  data,  and  DoD  mapping  data.  The 
initial  scenario  elements  shall  include  such  data  as,  but  not  limited  to:  assets  (including 
space  assets  and  sensors),  laydowns  and  Order  Of  Battle  (OOB)  information,  routes, 
weapons,  engagements,  threat  definitions  and  laydowns,  target  definitions  and  laydowns, 
events  and  activities  related  to  information  warfare,  all  sides  (multiple)  within  an 
exercise,  number  of  end  users,  and  end  users’  views  of  the  wargame.  The  wargame 
conditions  include  shall  such  data  as,  but  not  limited  to:  wargame  configuration 
(including  communications,  real  world  interfaces),  exercise  report  data  and  collection, 
wargame  configuration,  wargame  speed,  data  collection  and  storage,  environmental 
conditions,  and  level  of  aggregation/deaggregation.  The  scenario  elements  and  wargame 
conditions  shall  be  adjustable  during  an  exercise  by  the  technical  controllers. 

Scenario  generation  tools  shall  access  the  static  environmental  data  present  in  the 
common  facilities  to  create  a  dynamic  environment  for  the  system,  capturing  the  effects 
of  weather  and  operations  on  the  mission  space  (e.g.,  smoke,  fog,  biological  and  chemical 
weaponry)  and  ensuring  distributed  consistency  of  the  environment  through  out  the 
exercise. 
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The  NASM  system  shall  provide  the  ability  to  permit  the  technical  controllers  to  store 
complete  and  partial  scenarios  and  scenario  data.  NASM  shall  store  scenarios  and 
scenario  data  in  such  a  manner  that  promotes  reusability  of  the  scenarios  and  scenario 
data.  The  NASM  system  shall  provide  the  technical  controllers  with  the  ability  to  catalog 
and  retrieve  stored  scenarios. 

3.2.1.2  Pre-Exercise  Simulation  System  Support 

Exercise  preparation  shall  support  capabilities  such  as,  but  not  limited  to:  establishing 
the  exercise  configuration;  and  supporting  verification  and  validation  of  scenario  data  and 
scenarios. 

3.2. 1.3  Establish  Exercise  Configuration 

The  NASM  system  shall  provide  the  technical  controllers  with  the  capability  to  define  the 
exercise  system  configuration  for  all  types  of  users.  This  capability  provides  the 
technical  controllers  with  the  capability  to  select  the  physical  workstation  configuration 
for  the  exercise.  The  physical  exercise  configuration  shall  be  changeable  (manually  or 
dynamically)  during  an  exercise. 

The  technical  controllers  shall  be  allowed  to  define  the  simulation  configuration.  The 
simulation  configuration  shall  define  data  such  as,  but  not  limited  to:  the  physical  real 
world  system  connectivity  (simulated  or  live),  external  simulation  system  interfaces,  level 
of  aggregation/deaggregation,  and  communication  links  that  will  be  modeled  as  part  of 
the  simulation  system.  Tools  shall  be  provided  to  stress  test  the  physical  exercise 
configuration  for  load  and  performance  criteria  without  executing  the  actual  exercise. 


3.2.1.4  Scenario  Verification  and  Validation 

The  pre-simulation  capabilities  shall  support  the  scenario  verification  and  validation 
process.  The  scenario  verification  and  validation  process  shall  allow  the  user  to  preview 
the  scenario  based  upon  time,  event,  entities,  and  scenario  notes.  During  the  scenario 
verification  and  validation,  the  technical  controller  may  be  allowed  to  modify  the 
scenario. 


3.2.2  Simulation  System  Execution 

NASM  shall  provide  the  ability  to  execute  the  scenarios  to  support  the  operational 
training  and  readiness,  as  well  as  educational  communities.  During  the  simulation 
execution,  the  NASM  system  shall: 
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a.  accept  and  respond  appropriately  to  user  input  from  the  technical  controllers 
and  end-users; 

b.  create  and  maintain  an  event  log  in  a  time-ordered  sequence  of  all  events 
occurring  in  the  simulation  execution,  and  at  periodic  or  controller  initiated 
checkpoints,  including  state  saves  to  adequately  to  restart  the  simulation  at 
given  checkpoints; 

c.  automatically  collect  and  store  on-line  all  data  (e.g.,  AAR  report  data, 
performance,  metrics)  that  has  been  selected  for  collection  by  the  technical 
controllers  without  degrading  the  performance  of  the  NASM  simulation 
execution; 

d.  execute  at  the  wargame  simulation  speed  to  the  logical  time  selected  by  the 
technical  controllers,  including  discontinuous  time  changes; 

e.  interface  with  external  simulation  systems  and/or  real  world  C4I  interfaces  as 
specified  in  the  simulation  configuration; 

f.  be  capable  of  executing  standalone  (unfederated)  or  as  part  of  a  federated 
simulation  system;  and 

g.  the  ability  to  define  and  store  user  defined  report  formats. 


The  NASM  system  simulation  execution  shall  support  the  following  characteristics: 
sides,  aggregation/deaggregation,  behavioral  representations,  ground  truth,  and 
simulation  time. 


3.2.2.1  Sides 

NASM  shall  represent  multiple  sides  (at  a  minimum  of  1 0),  including  multiple  services 
from  multiple  nations  in  coalition  (with  joint  forces  component  commanders),  neutral 
forces  (which  may  convert  to  active  participants  during  exercise  execution),  and  opposing 
forces  (with  similar  organizational  characteristics).  All  sides  shall  have  the  same 
simulation  system  functional  capabilities  (i.e.,  think,  move,  communicate,  shoot,  etc.). 
However,  within  NASM,  each  side  shall  have  the  capability  to  act  or  be  represented 
differently.  NASM  shall  have  the  capability  of  allowing  each  side  to  have  multiple  views 
allowing  the  perceived  truth  for  each  view  of  a  side  to  be  different . 
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3.2.2.2  Aggregation/Deaggregation 

NASM  shall  provide  for  multiple  user  communities  by  providing  multiple  levels  of 
resolution  (NOT  variable  resolution  which  infers  a  continuous  analog  resolution  rather 
than  the  actual  requirements  for  steps  of  resolution)  with  aggregation  and  deaggregation 
of  decisions  and  entity  representations  simulations  at  all  levels  (from  component  through 
units).  At  the  aggregate  level,  NASM  shall  allow  for  two  or  more  entities  to  be  viewed  as 
a  single  entity  during  the  simulation  (e.g.,  a  flight).  Behavior  shall  be  represented 
discretely  at  each  level  of  aggregation  (e.g.,  a  flight  has  unique  behaviors  which  must  be 
modeled  explicitly,  not  simply  the  addition  of  its  component  parts).  Interactions  among 
simulated  entities  shall  be  resolved  at  comparable  levels  of  resolution,  only  requiring 
decomposition  to  the  platform  level  or  below  as  required.  NASM  shall  provide  the 
ability  for  aggregated  entities  to  be  viewed  as  individual  entities  during  an  exercise.  See 
Section  6.0  for  more  information  on  Aggregation/Deaggregation. 


3.2.2.3  Behavioral  Representation 

NASM  shall  represent  the  full  range  of  probable  behaviors  of  forces  and  all  supporting 
activities  (e.g.  command  centers).  NASM  shall  provide  for  Warfighter-in-the-Loop 
Semi-Automated  Forces  (SAFORs)  and  fully  automated  Computer  Generated  Forces 
(CGFs)  to  represent  both  friendly,  neutral,  and  Opposing  Forces  (OPFOR)  at  all 
applicable  levels  from  platform  (thinker)  entity  task  frames  to  command  decision  logic. 
Metaobject  (multiple  resolution)  and  Multiobject  (similar  and  dissimilar  object  groups) 
behavior  shall  be  supported.  A  NASM  exercise  shall  be  able  to  run  without  any 
personnel  resources  being  utilized  for  control  representation  of  opposing  forces 
(intelligent  enemy)  or  any  forces  (fully  automated).  Entity  behavior  (platform  through 
command  centers)  shall  be  modeled  discretely  at  the  respective  level  of  representation). 


3.2.2.4  Ground  Truth 

The  simulation  system  shallsupport  ground  truth  and  entity  based  perceived  truth. 

Ground  truth  shall  be  maintained  separate  and  distinct  for  use  by  the  simulation 
executive,  and  externally  by  the  exercise  control  staff.  Perceived  truth  shallbe  used  for 
automated  and  semi-automated  behavior  decision  processing  and  Warfighter  In  The  Loop 
(WITL)  participants.  The  simulation  system  shall  allow  entity  interactions  (platform  to 
unit)  using  only  perceived  truth. 


3.2.2.5  Simulation  Time 
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NASM  shall  have  the  ability  to  run  at  rates  ranging  from  Slower  than  Real  Time  (SRT), 
to  Near  Real  Time  (NRT)  to  Faster  than  Real  Time  (FRT).  Simulation  time  shall  include 
event  driven  synchronous,  event  driven  asynchronous  and  scaled  time  driven  (real  time: 
simulation  time)  as  a  subset  of  a  discrete  event.  Time  compression  factors  shall  be 
selectable  within  a  range  from  1/1  Oth  to  100  times  real-time.  NASM  shall  be  capable  of 
executing  faster  than  real  time  (at  least  2:1)  while  supporting  a  multiple  Major  Regional 
Contingency  (MRC)  scenario  with  maximum  level  of  resolution  and  full  participation  of 
training  audiences  down  to  the  wing  level.  With  SAFORs,  NASM  shallbe  capable  of 
executing  a  multi-MRC  scenario  at  a  speed  of  10  to  1.  With  CGF  and  only  high  level 
inputs,  NASM  shall  be  capable  of  executing  at  a  speed  to  100:1  (30  days  in  7.2  hours). 
NASM  will  be  capable  of  executing  at  a  speed  of  240  to  1  (15-30  days  in  3  hours). 
NASM  shall  be  extensible  to  support  the  maximum  speed  of  1000:1  (This  speed  is 
envisioned  for  analytical  purposes  only.) 

NASM  shall  be  capable  of  jumping  backward  in  time  to  support  simulation  restart  or 
simulation  replay. 

In  addition  to  the  time  ratio,  a  variable  time  step  interval  between  1  and  60  seconds  shall 
be  supported.  Nominally,  a  time-step  of  6  seconds  is  desired. 


3.2.3  Post  Exercise 

The  NASM  system  shall  provide  the  ability  to  debrief  exercise  participants  and  support 
the  After  Action  Review  (AAR)  process  including  the  exercise  hot-wash.  The  NASM 
system  shall  provide  the  users  with  the  ability  to  assess  the  effectiveness  of  the  exercise 
and  to  provide  realistic  training  and  conduct  post  exercise  analysis  (e.g.,  examination  of 
doctrinal  issues,  analysis  of  logistics  and  force  support  issues,  and  evaluate  force 
employment  operations,  and  intelligence  issues).  The  post  exercise  capabilities  include 
the  ability  to  generate  predefined  and  user  defined  reports,  and  to  perform  simulation 
system  playback. 


3.2.3. 1  After  Action  Review  (AAR)  Process 

In  support  of  the  AAR  process,  NASM  shall  provide  the  capability  to  track  special  or 
high  interest  information,  provide  automatic  detection  of  events  based  upon  common 
errors,  compare  ground  truth  information  from  the  simulation  databases  with  each  of  the 
end  users  (i.e.,  players)  perceived  truth. 


3.2.3.2  Predefined  and  User  Defined  Reports 
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The  NASM  system  shall  have  a  standard  set  of  predefined  reports.  The  standard  reports 
shall  include  data  reports  such  data  as,  but  limited  to:  damage  assessment,  weapons 
expended,  aircraft  losses,  mission  results,  kills  claimed,  and  status  reports.  Data 
necessary  for  the  predefined  reports  shall  be  collected  automatically.  Predefined  reports 
shall  be  automatically  generated  at  the  end  of  an  exercise,  as  appropriate. 

NASM  shall  provide  the  technical  controllers  with  the  ability  to  generate  user-defined 
reports  during  the  simulation  system  execution  and  post  exercise  analysis.  The  user- 
defined  reports  can  be  generated  based  upon  simulation  events,  results,  and/or  time. 

After  action  reviews  shall  be  available  for  hot  wash  within  two  hours  of  end  of  exercise. 

3.2.3.2.1  Post  Exercise  Analysis 

Tools  shall  be  provided  to  allow  in  depth  post-exercise  analysis  based  on  archived  data. 

3.2.3.3  Simulation  System  Playback 

As  part  of  the  post  exercise  debrief  the  NASM  technical  controllers  shall  have  the  ability 
to  playback  a  portion  of  an  exercise  or  a  complete  exercise. 


3.3  Missions 

NASM  shall  provide  appropriate  models  to  represent  all  the  AF  missions  including 
aerospace,  military  operations  other  than  war  (MOOTW),  information  warfare,  and 
special  operations.  NASM  shall  have  the  capability  to  support  exercises  that  transition 
between  all  the  AF  missions.  The  models  shall  be  based  upon  official  data.  The  NASM 
system  shall  meet  the  Validation,  Verification,  and  Accreditation  criteria  in  accordance 
with  USAF  directives  and  guidance. 


3.3.1  Aerospace  Missions 

The  NASM  system  includes  representations  of  the  following  types  of  missions: 
aerospace  control,  force  application,  force  enhancement,  and  force  support. 


3.3. 1.1  Aerospace  Control 

NASM  shall  have  the  capability  to  model  aerospace  control  missions:  counterair  and 
counterspace.  Both  of  these  missions  can  be  divided  into  offensive  and  defensive 
objectives. 
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a.  Counterair 

Offensive  aerospace  control  shall  include  the  ability  to  seek  out  and  neutralize 
or  destroy  enemy  aerospace  forces  and  ground-based  defenses.  The  objective 
of  counterair  is  control  of  air.  The  following  types  of  counterair  (offensive  and 
defensive)  shall  be  modeled  within  NASM:  sweep,  escort,  air  defense,  and 
airborne  electronic  warfare. 

b.  Counterspace 

Defensive  aerospace  control  shall  model  that  ability  to  control  operations, 
detect,  identify,  intercept,  and  destroy  enemy  aerospace  forces.  The  objective 
of  counterspace  is  control  of  space. 


3.3. 1.2  Force  Application 

Force  application  missions  apply  combat  power  against  surface  targets  excluding 
missions  whose  objectives  are  aerospace  control.  NASM  shall  model  the  following  types 
of  force  application  missions:  strategic  attack,  interdiction,  and  Close  Air  Support 
(CAS). 


a.  Strategic  Attack:  The  objective  of  a  Strategic  attack  mission  is  to  destroy  or 
neutralize  an  enemy’s  war-sustaining  capabilities  or  will  to  fight. 

b.  Interdiction:  The  objective  of  an  Interdiction  mission  is  to  delay,  disrupt, 
divert,  or  destroy  an  enemy’s  military  potential  before  it  can  be  brought  to  bear  against 
friendly  forces. 

c.  CAS:  CAS  missions  support  the  surface  commander  by  destroying  or 
neutralizing  enemy’s  forces  that  are  in  proximity  to  friendly  forces. 


3.3. 1.3  Force  Enhancement 

Force  enhancement  increases  the  ability  of  aerospace  and  surface  forces  to  perform  their 
missions.  NASM  shall  model  the  following  types  of  force  enhancement  missions:  airlift, 
air  refueling,  spacelift,  electronic  combat  controls,  and  intelligence,  surveillance  and 
reconnaissance. 

a.  Airlift:  Airlift  provides  for  transportation  of  resources  (people,  equipment, 
materiel)  rapidly  without  regard  to  surface  obstacles. 
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b.  Air  Refueling:  Increases  the  ability  of  aircraft  by  extending  their  range, 
payload,  and  endurance. 

c.  Spacelift:  Spacelift  transports  resources  (people,  equipment,  materiel)  to  and 
through  space. 

d.  Electronic  combat:  Electronic  combat  controls,  neutralizes  or  destroys  the 
enemy’s  electromagnetic  capabilities. 

e.  Intelligence,  Surveillance  and  Reconnaissance:  Intelligence,  surveillance  and 
reconnaissance  provides  data  needed  for  effective  combat  operations. 


3.3.1.4  Force  Support 

Force  support  must  sustain  operations  that  contribute  to  the  success  of  aerospace  forces. 
NASM  shall  model  the  following  force  support  functionality:  base  operability  and 
defense  missions,  logistics,  combat  support,  and  on-orbit  support. 

a.  Air  Base  Operability  (ABO)  and  Defense:  Air  Base  Operability  and  defense 
includes  defending  an  aerospace  installation  from  attack,  helping  aerospace  forces  survive 
an  attack,  and  returning  installations  to  full  capability  post  attack. 

b.  Logistics:  Provides  assets  for  and  sustains  aerospace  forces. 

c.  Combat  support:  Combat  support  provides  support  to  organizations  and 
personnel  in  operational  condition. 

d.  On-orbit  support:  On-orbit  support  keeps  platforms  in  space  operating  as 
effectively  and  efficiently  as  possible. 


3.3.2  MOOTW  Missions 

NASM  shall  have  the  capability  to  support  MOOTW  exercises.  MOOTW  operations 
include  three  classes:  combat,  noncombat,  and  an  overlapping  between  combat  and 
noncombat.  NASM  shall  provide  the  capability  to  create  realistic  (including  joint 
interagency,  non-governmental  organizations,  private  voluntary  organizations,  media 
participation,  and  space  force)  and  challenging  exercises  to  support  the  training  of  all  the 
MOOTW  missions.  NASM  shall  be  capable  of  creating  and  executing  exercises  that 
emphasize  employment,  deployment,  and  redeployment  phases,  as  well  as  transitions  to 
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and  from  war.  The  NASM  MOOTW  models  shall:  interface  with  C4I  systems,  employ 
appropriate  laws,  and  include  logistics  coordination. 


3.3.2. 1  Combat  MOOTW  Missions 

NASM  shall  support  the  following  combat  MOOTW  missions:  enforcement  of 
sanctions,  enforcement  of  exclusion  zones,  protection  of  shipping,  strikes  and  raids. 
Aerospace  and  space  contributions  to  the  combat  MOOTW  missions  shall  include 
capabilities  such  as,  but  are  not  limited  to:  airlift,  close  air  support,  combat  search  and 
rescue,  counterair,  counterspace,  interdiction,  strategic  attack,  surveillance,  and 
reconnaissance. 


3.3.2.2  Noncombat  MOOTW  Missions 

NASM  shall  support  the  following  noncombat  missions:  arms  control  support,  domestic 
support  operations,  foreign  humanitarian  assistance,  nation  assistance,  show  of  force,  and 
support  to  insurgency. 


3.3.2.3  Overlapping  MOOTW  Missions 

NASM  shall  support  the  following  missions  that  overlap  between  combat  and 
noncombat:  combating  terrorism,  counterdrug  operations,  ensuring  freedom  of 
navigation,  noncombatant  evacuation  operations,  peace  operations,  recovery  operations. 


3.3.3  Special  Operations  Missions 

NASM  shall  have  the  capability  to  model  for  the  purposes  of  training  special  operations 
missions.  These  missions  shall  include:  unconventional  warfare,  direct  action 
operations,  special  reconnaissance,  counterterrorism,  foreign  internal  defense,  and 
psychological  operations.  NASM  shall  have  the  capability  to  create  and  execute 
exercises  that  include  the  special  operations  missions. 


3.3.3.1  Unconventional  Warfare 

NASM  shall  have  the  capability  to  model  unconventional  warfare  that  includes  guerrilla 
warfare  and  other  direct  offensive,  low  visibility,  covert  or  clandestine  operations,  as  well 
as  the  indirect  activities  of  subversion,  sabotage,  intelligence  collection,  and  evasion  and 
escape. 
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3.33.2  Direct  Action  Operations 

NASM  shall  provide  the  capability  to  model  direct  action  operations  that  are  short- 
duration  strikes  and  other  small  scale  offensive  actions  principally  taken  by  Special 
Operations  Forces  (SOF)  to  seize,  destroy,  or  inflict  damage  on  a  specified  target;  or  to 
destroy,  capture,  or  recover  designated  personnel  or  material. 


3.3.33  Special  Reconnaissance 

NASM  shall  provide  the  capability  to  model  reconnaissance  and  surveillance  actions 
conducted  by  SOF  to  obtain  or  verify,  by  visual  observation  or  other  collection  methods, 
information  concerning  capabilities,  intentions,  and  activities  of  an  actual  or  potential 
enemy. 

3.33.4  Counterterrorism 

NASM  shall  have  the  capability  to  model  counterterrorism  which  consists  of  offensive 
measures  taken  to  prevent,  deter,  and  respond  to  terrorism,  including  intelligence 
gathering  and  threat  analysis  in  support  of  those  measures. 


3.33.5  Foreign  Internal  Defense  (FID) 

NASM  shall  have  the  capability  to  model  FID.  FID  provides  U.S.  military  expertise  to 
other  governments  in  support  of  their  internal  defense  and  development  efforts. 


3.3.4  Information  Warfare 

NASM  shall  have  the  capability  to  include  events  and  activities  related  to  information 
warfare.  The  events  and  activities  shall  include  actions  taken  to  deny,  exploit,  corrupt,  or 
destroy  an  adversary’s’  information  and  its  functions,  while  protecting  friendly  forces 
against  similar  actions  and  exploiting  organic  military  information  functions. 

Information  warfare  representations  shall  include  the  following  functionality: 
Psychological  operations,  military  deception,  electronic  warfare,  physical  attack, 
information  attack,  and  security  measures.  NASM  shall  allow  these  events  and  activities 
to  occur  during  the  simulation  execution. 
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3.3.4. 1  Psychological  Operations 

Psychological  operations  convey  selected  information  and  indicators  to  foreign  audiences 
to  influence  their  emotions,  motives,  objective  reasoning  and  ultimately  the  behavior  of 
foreign  governments,  organizations,  groups,  and  individuals.  The  purpose  of  PSYOP  is 
to  induce  or  reinforce  foreign  attitudes  and  behavior  favorable  to  the  originator’s 
objectives.  The  affect  of  PSYOP  shall  be  adequately  represented  within  the  simulations. 
NASM  shall  have  the  capability  to  model  PSYOP  forces  that  can  support  strategic, 
operational,  tactical,  or  consolidation  PSYOP  objectives  by  providing  intelligence,  leaflet 
delivery,  or  media  broadcasts. 

3.3.4.2  Military  Deception 

Military  Deception  shall  be  represented  within  NASM.  Military  deception  seeks  to 
mislead  foreign  decision  makers,  causing  them  to  act  in  accordance  with  the  originator's 
objectives.  Deception  strategies  may  support  national  policies,  military  service  programs, 
or  tactical  operations.  Measures  are  designed  to  distract  from,  or  provide  cover  for, 
military  operations.  These  measures  require  accurate  intelligence  on  the  adversary’s 
cultural,  political,  and  doctrinal  perceptions  to  be  modeled  through  the  use  of  assets 
represented  within  the  simulation.  Scenario  planners  and  technical  controllerswill  then  be 
able  to  exploit  and  manipulate  those  biases  which  will  affect  the  simulation  execution. 


3.3.4.3  Electronic  Warfare  (EW) 

EW  shall  be  represneted  as  is  military  actions  involving  the  use  of  electromagnetic  and 
directed  energy  to  control  the  electromagnetic  spectrum  or  to  attack  an  adversary.  EW 
creates  a  correct  representation  of  an  electronic  sanctuary  in  which  friendly  aircraft  can 
operate  during  air  and  ground  operations.  This  sanctuary  enables  strike  and  counterair 
aircraft  to  proceed  to  and  from  their  targets  and  to  fully  exploit  their  modem  technology 
weapons  in  relative  safety. 


3.3.4.4  Physical  Attack 

Physical  Attack  shall  be  represented  which  destroys  information  systems  through  the 
conversion  of  stored  energy  into  destructive  power.  The  coupling  of  Precision  Guided 
Munitions  (PGM)  and  advanced  delivery  platforms  provide  the  required  precision  to 
accurately  attack  the  adversary’s  C2.  It  increases  the  utility  to  attack  C2.  Additionally, 
the  few  aircraft  required  per  target  permits  simultaneously  striking  a  large  array  of  the 
adversary’s  information  operations  vice  sequentially. 
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3.3.4.5  Information  Attack 

Information  Attack  shall  be  represented  which  encompasses  special  communications  and 
computer  activities  taken  to  manipulate  or  destroy  an  adversary's  information  functions. 
Penetration  of  an  enemy’s  information  systems  has  great  value  in  combat  because  it 
offers  the  ability  to  incapacitate  an  adversary  with  reduced  exposure  to  friendly  forces. 
By  using  non-traditional  tools,  the  conventional  sorties  can  be  saved  for  other  targets. 
Manipulation  of  data  bases  or  parameters  of  reporting  systems  can  cause  incorrect 
information  for  decision  making,  or  destroy  the  enemy’s  confidence  in  the  system.  An 
effective  information  attack  could  force  an  adversary  to  use  less  technical  means  because 
of  friendly  intrusion  into  the  system. 


3.3.4.6  Security  Measures 

Security  measures  include  programs  designed  to  protect  information  that  could  be 
corrupted,  destroyed,  or  exploited.  Operations  Security  (OPSEC)  and  Information 
Security  (INFOSEC)  makeup  the  two  basic  elements  of  security  measures.  OPSEC  is  the 
process  of  identifying  critical  information  and  subsequently  analyzing  friendly  actions  in 
order  to  preclude  observation  by  adversary  intelligence  systems.  INFOSEC  relates  to  the 
technical  protection  of  information  by  Communications  Security  (COMSEC)  and 
Computer  Security  (COMPUSEC)  programs.  INFOSEC  may  be  the  most  critical 
element  of  security  operations.  The  effects  of  security  measures  and  their  compromises 
shall  be  modeled  within  NASM. 


3.3.5  Simulated  Entities 

The  NASM  system  shall  provide  a  joint  synthetic  environment  battlespace  that 
realistically  portrays  the  real  world.  This  synthetic  environment  shall  model  the 
following  types  of  physical  entities  including,  but  not  limited  to:  assets,  sensors, 
equipment,  communication  links,  environmental  effects,  space  and  logistics.  The  NASM 
use  of  entities  means  the  entire  range  of  physical  characterizations  from  subcomponents 
to  units. 

In  addition  to  providing  models  that  represent  the  physical  entities,  the  NASM  system 
shall  provide  algorithms  that  accurately  model  the  following:  movement  and  navigation, 
detection,  flights,  targets,  pre  and  post  engagements  (AAM,  Beyond  Visual  Range 
(BVR),  Within  Visual  Range  (WVR),  Air  to  surface,  etc.),  disengagements,  damage 
assessment,  (collateral,  probability  of  kill,  damage  to  all  game  entities),  weapon 
effectiveness,  combat  assessments,  and  communications. 
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3.3.5.1  Assets 

The  NASM  system  shall  model  all  assets  necessary  to  support  Air  Force  training 
exercises  from  wing  up  to  and  including  the  Joint  Force  Air  Component  Commander 
(JFACC)  for  the  aerospace,  MOOTW,  information  warfare,  and  special  operations 
missions.  The  NASM  system  shall  model  all  assets  with  realistic  properties  and 
attributes.  Assets  include,  but  are  not  limited  to:  aircraft,  air  bases,  radar  sites,  missile 
sites,  sensors,  space  assets,  ships,  carriers,  Surface  to  Air  Missile  (SAM)  sites,  Short 
Range  Air  Defense  (SHORAD)  sites,  High  and  Medium  Range  Air  Defense  (HIMAD) 
sites, ,  satellites,  ground  forces  of  interest,  and  targets. 


3.3.5.1.1  Sensors 

NASM  shall  model  sensors  including  sensor  characteristics  and  sensor  operations  and 
activities.  Sensors  shall  be  modeled  realistically  including  the  effects  of  environmental 
conditions  (weather,  terrain  masking)  and  electronic  combat.  NASM  shall  model  all 
theater  level  collection  sensors  and  national  assets  (e.g.,  Rivet  Joint,  AW  ACS,  Joint 
Stars).  NASM  shall  model  these  sensors  to  the  level  of  detail  required  to  support 
battlestaff  training.  Simulated  sensor  outputs  shall  be  explicitly  modeled  to  support 
interfacing  with  real  world  systems. 


3.3.5.1.2  Equipment 

The  NASM  system  shall  model  equipment,  including  equipment  characteristics  and 
capabilities.  Equipment  to  be  modeled  within  NASM  shall  include,  but  not  be  limited  to: 
weapons,  radars,  jammers,  cruise  missiles,  theater  ballistic  missiles,  SAM,  Air  to  Surface 
Missile  (ASMs),  Air  to  Air  Missiles  (AAMs),  Transportable  Erector  Launcher  Systems 
(TELS),  bombs,  and  cargo. 


3.3.5.1.3  Communications  Links 

NASM  shall  model  the  communication  links  and  networks  used  within  a  theater  to 
accurately  reflect  the  real  world.  NASM  shall  provide  capabilities  to  define  theater 
communication  link  and  network  architectures  as  part  of  the  modeling  and  scenario 
generation  subsystem.  Failures  and  degradation  of  network  capabilities  in 
communications  links  shall  be  modeled  so  they  affect  interactions  within  the  simulation 
realistically. 
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3.3.5.2  Environmental  Effects 

The  NASM  system  shall  realistically  model  environmental  effects  on  real  world  system 
interfaces  and  aerospace  weapons  systems  during  training  exercises.  These 
environmental  effects  shall  be  considered  during  the  exercise  execution.  The  technical 
controller  shall  have  the  ability  to  change  the  environmental  effects  during  an  exercise. 
NASM  environmental  effects  include,  but  are  not  limited  to:  weather,  day  and  night 
effects,  air,  space,  sea,  and  terrain  (natural  and  man-made),  including  dynamic  terrain , 
electromagnetic,  optic,  and  acoustic  propagation,  and  interactions  between  environments. 

3.3.5.3  Space 

NASM  shall  model  the  following  functionality:  navigation  including  Global  Positioning 
System  (GPS)  satellites  and  processing;  communication  satellites  and  links;  missile 
warning  systems;  environmental  monitoring  satellites;  and  spacelift,  including  space 
based  assets. 


3.3.5.4  Logistics 

NASM  models  shall  include  sufficient  logistics  detail  and  adequate  logistics  related 
events  to  simulate  activities  necessary  to  support  exercises  at  the  Air  Operations  Center 
(AOC)  and  Wing  Operations  Center  (WOC)  and  train  AOC  and  WOC  logistics  support 
personnel. 


3.4  Interfaces 

NASM  interface  categories  include  real  world  interfaces,  other  simulation  systems, 
JSIMS,  and  virtual  system  interfaces.  To  the  maximum  extent  feasible  NASM  shall 
use/adopt  the  HLA  Run-Time  Infrastructure  (RTI)  adopted  by  JSIMS  or  develop  an  HLA 
RTI  to  provide  interoperability  with  other  simulation  systems  and  real  world  C4I 
systems. 

3.4.1  HLA 

The  DMSO  DOD  HLA  interface  specifications  provide  a  description  of  the  RTI  services 
required  for  achieving  interoperability  among  the  next  generation  of  DoD  simulations. 
Under  HLA,  models  shall  to  conform  to  the  Object  Model  Templates,  interface  with  a 
formalized  RTI  definition,  and  applicable  intra-federation  standards.  The  first  federation 
will  be  JSIMS,  but  we  expect  that  NASM  will  become  part  of  other  HLA  federations, 
each  with  its  own  Federation  Object  Models. 
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3.4.1.1  Run-Time  Infrastructure 

The  HLA  RTI  provides  services  to  simulations  in  a  way  that  is  analogous  to  how  a 
distributed  operating  system  provides  services  to  applications.  These  interfaces  are 
arranged  into  the  five  basic  RTI  service  groups:  time  management,  federation 
management,  declaration  management,  object  management,  and  ownership  management. 
NASM  shall  provide  the  functionality  of  each  of  the  five  RTI  services  groups. 

The  five  service  groups  describe  the  interface  between  the  simulations  and  the  RTI  and 
the  software  services  provided  by  the  RTI  for  use  by  compliant  simulations.  The  critical 
functions  included  in  the  RTI  as  they  relate  to  simulations  are: 

-  Participate  in  distributed  simulation  management 

-  Make  import  and  export  declarations  to  moderate  data  flow 

-  Interact  with  objects  owned  by  another  simulation  by  exchanging  public 
attributes  and  events  through  the  interface 

-  Dynamically  transfer  attribute  ownership 

Specifics  related  to  the  functions  described  here  can  be  found  in  the  draft  DMSO  DOD 
HLA  Interface  Specification.  Where  applicable,  NASM  shall  adhere  to  the  DMSO  DOD 
HLA  Interface  specification  in  the  following  functional  areas: 

3.4.1.2  Time  Management 

NASM  shall  have  the  capability  to  coordinate  the  advance  of  time  and  the  exchange  of 
events  between  simulations  in  a  federation.  A  federation  of  simulations  can  be  treated  as 
a  single,  large  simulation.  NASM  Simulation  time  shall  include  event  driven 
synchronous,  event  driven  asynchronous  and  logical  time  driven  (real  time  and 
simulation  time)  as  a  subset  of  discrete  event. 

3.4. 1.3  Federation  Management 

NASM  shall  provide  the  capability  to  provide  Federation  Management  which  includes 
the  capability  to  create,  dynamically  control,  modify,  and  delete  a  federation.. 

3.4.1.4  Declaration  Management 

NASM  shall  have  the  capability  to  declareto  the  RTI  their  desire  to  both  generate  and 
receive  object  state  information.  In  addition  to  object  state  information,  the  interactions 
generated  and  received  by  a  simulation  must  also  be  declared.  When  a  simulation 
publishes  data,  that  data  is  available  to  all  subscribing  simulations. 
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3.4.1.5  Object  Management 

NASM  shall  have  the  capabilty  to  create,  modify,  and  delete  objects  and  their 
interactions. 

3.4.1.6  Ownership  Management 

NASM  shall  provide  the  capability  to  allow  simulations  to  transfer  the  responsibility  for 
modeling  various  object  attributes.  The  ownership  management  services  include 
continuity  of  ownership  and  symmetry  of  negotiations.  Continuity  of  ownership  are 
services  which  do  not  allow  the  current  owner  of  an  attribute  to  cease  publication  of 
values  until  the  RTI  has  found  a  new  owner  that  can  assume  that  responsibility. 
Symmetry  of  negotiation  refers  to  the  ability  of  a  simulation  to  initiate  both  the 
acquisition  and  divestiture  of  attribute  ownership. 


3.4.2  Real  World  System  Interfaces 

The  NASM  simulation  system  shall  be  capable  of  training  USAF  battlestaffs  on  their  real 
world  C4I  equipment  and/or  simulated  representations  of  the  same  equipment.  NASM 
will  fully  support  C4I  through  1)  real  world  system  one  and  two-way  data  interfaces,  and 
2)  transparent  user  interface  to  NASM  using  real  world  equipment  (Computer-Human 
Interface).  NASM  must  be  capable  of  simulating  all  source  Intelligence  systems  that 
provide  inputs  to  Theater  C4I  systems  (even  if  the  real  world  systems  are  not  physically 
present).  Systems  will  range  from  air  campaign  planning  tools  down  to  command  center 
and  airborne  C2  systems.  To  enhance  realism,  NASM  must  incorporate  real  world  data 
bases  into  the  simulation  system  and  distribute  the  artificial  mission  environment  to 
participating  battlestaffs  in  the  same  manner  as  such  information  would  be  distributed 
during  an  actual  contingency.  Interface  to  these  systems  must  be  in  their  native  system 
protocols.  Where  possible,  the  NASM  HLA  RTI  shall  be  the  mechanism  to 
accommodate  interoperability  to  the  real  world  systems. 

NASM  shall  provide  the  ability  to  manually  input  data  in  lieu  of  real  world  system 
interfaces  and  manually  override  data  that  is  input  from  the  real  world  system  interfaces. 
The  NASM  shall  have  direct  interfaces  with  the  following  real  world  systems:  TBMCS, 
C2IPS,  JDISS,  TIBS,  TRAP,  TADIL,  SOFPARS.  Each  of  the  interfaces  are  described 
below.  NASM  shall  be  capable  of  receiving,  generating,  and  transmitting  TADIL  A,  B, 
and  J  messages.  NASM  shall  indirect  interfaces  with  the  following  real  world  systems: 
ADANS,  JCMT,  GDSS,  CM  ARP,  TEP. 


3.4.2. 1  Theater  Battle  Management  Core  Systems  (TBMCS) 

a.  CTAPS 
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During  pre-simulation  NASM  shall  be  capable  of  exporting  and  importing 
scenario  data  from  and  to  CTAPS  databases. 

During  simulation  execution,  NASM  shall  be  capable  of: 

o  receiving  and  using  the  following  messages  from  CTAPS:  USMTF 
ATOCONF,  USMTF  ATO,  and  USMTF  ACO. 

o  extracting  and  using  an  embedded  ACO  from  an  USMTF  ATO  or  USMTF 
ATOCONF  message. 

o  generating  and  transmitting  messages  and  reports  (e.g.,  MISREPs)  over 
real  world  data  links. 

o  accommodate  Master  Attack  Plan  (MAP)  changes  directly  from  the  Air 
Campaign  Planning  Tool  (ACPT) 

b.  Wing  Command  and  Control  System  (WCCS) 

During  pre-simulation  NASM  shall  be  capable  of  exporting  and  importing 
scenario  data  from  and  to  WCCS  databases.  During  simulation  execution,  NASM 
shall  be  capable  of: 

o  receiving  and  using  the  following  messages  from  WCCS:  USMTF  ATO 
and  TBD. 

o  extracting  and  using  an  embedded  ACO  from  an  USMTF  ATO  or  USMTF 
ATOCONF  message. 

o  generating  and  transmitting  messages  over  real  world  data  links  following 
the  following  data:  TBD. 

c.  Combat  Intelligence  System  (CIS) 

NASM  shall  receive  target  Battle  Damage  Assessment  (BDA)  data  an  integrate 
into  the  scenario  planning  process. 

d.  Standalone  Tactical  Operational  Message  Processing  System  (STOMPS) 

TBD. 


3.4.2.2  Command  Control  Information  Processing  System  (C2IPS) 
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NASM  shall  interface  with  C2IPS. 


3.4.2.3  Joint  Deployable  Intelligence  Support  System  (JDISS) 

During  pre-simulation,  NASM  shall  be  capable  of  importing  and  exporting  scenario  data 
from  and  to  the  JDISS  databases. 


3.4.2.3  Special  Operations  Forces  Planning  and  Rehearsal  System  (SOFPARS) 

TBD. 


3.4.2.4  Tactical  Information  Broadcast  System  (TIBS) 

NASM  shall  generate  and  transmit  a  TIBS  data  stream  to  command  and  analysis 
locations  participating  in  the  exercise  using  operational  data  links  supporting  TIBS 
message  protocols.  Where  applicable  to  the  NASM  models,  NASM  shall  be  capable  of 
accepting  and  using  a  TIBS  data  through  an  interface  to  operational  TIBS  compliant 
tactical  data  links. 

3.4.2.5  Tactical  Receive  Equipment  (TRE)  and  Related  Applications  (TRAP) 

NASM  shall  provide  a  capability  to  use  TRAP  terminal  equipment  as  an  operational  data 
link  supporting  TIBS  and  other  TRAP  message  protocols.  NASM  shall  be  capable  of 
sending  appropriate  information  into  connected  TRAP  terminals  for  transmission  to 
connected  facilities.  Where  applicable  to  the  NASM  models,  NASM  shall  be  capable  of 
obtaining  information  from  the  TRAP  terminals  and  using  the  information. 

3.4.3  External  Simulation  Systems  Interfaces 

NASM  shall  interoperate  with  other  current  and  future  constructive  simulations,  such  as 
but  not  limited  to:  WARSIM  2000,  JECEWSI,  and  JSIMS  via  the  HLA  RTI. 

3.4.3. 1  WARSIM  2000  Interface 

NASM  shall  support  a  bi-directional  interface  via  the  HLA  to  WARSIM  2000. 

3.4.3.2  JECEWSI  Interface 
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JECEWSI  is  a  joint  electronic  warfare  model  that  simulates  electronic  combat  and 
electronic  warfare.  The  NASM  interface  with  JECEWSI  shall  be  bi-directional.  NASM 
shall  receive  the  jammer  power  and  the  electronic  degradation  factors  for:  C3, 
acquisition  capability,  launch  capability,  and  self-protection  jammer  (SPJ).  NASM  shall 
send  to  JECEWSI  the  fixed  wing  aircraft  information,  aircraft  update  information  (e.g., 
position,  speed,  status),  emitter  types  and  status. 


3.4.3.3  JSIMS  Interface 

NASM  shall  be  capable  of  operating  as  a  stand  alone  model  or  integrated  with  JSIMS. 
NASM  shall  provide  correct  presentation  of  aerospace  doctrine  in  exercises  by  providing 
the  air  and  space  objects  (both  system  and  behavioral  representation)  for  use  within  the 
JSIMS  federation.  NASM  shall  be  capable  of  taking  advantage  of  the  services  and  other 
components  of  JSIMS  when  executing  stand  alone  or  in  a  Federation.  NASM  shall 
provide  all  the  air  and  space  representations  models  necessary  to  support  JSIMS 
including  functionality  below  the  joint  components. 


3.4.4  Virtual  Interfaces 

NASM  will  interoperate  with  virtual  simulators  and  simulations  and  instrumented 
systems  using  protocols  consistent  with  the  DoD  High  Level  Architectures.  All  such 
entity  representations  will  be  as  surrogate  objects  within  NASM. 


3.5  System  Architecture/Software  Requirements 

The  software  shall  be  developed  to  support  the  following  open  system  characteristics: 

o  provide  a  “core”  of  support  software  and  a  suite  of  software  tools  and 
standards  compliant  with  HLA  architecture  (and  JSIMS)  where  necessary; 

o  reduce  the  number  of,  and  special  training  required  for,  system  administrators, 
network  administrators,  and  other  exercise  support  personnel; 

o  minimize  life-cycle  costs,  and  be  logistically  supportable; 

o  be  flexible,  extensible,  and  evolvable  to  support  current  and  emerging 

commercial  standards  and  incorporate  upgrades,  and  commercially  available 
software; 
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o  provide  sufficient  flexibility  and  performance  to  support  changes  and 
extensions  to  the  models; 

o  use  COTS,  GOTS,  and  NDI  to  the  maximum  extent  feasible.  It  shall 

capitalize  on  industry  accepted  standards  and  commercially  available  products 
to  the  maximum  extent  possible  to  support  the  system  requirements; 

o  use  well-defined  application  program  interfaces  between  the  models  and  the 
support  services, 

o  be  portable  and  have  the  ability  to  execute  across  heterogeneous  platforms.  It 
shall  be  capable  of  being  transferred  between  homogenous  and  heterogeneous 
platforms  with  minimal  or  no  modifications; 

o  optimize  the  interdependencies  between  software  components  so  that  the 
impact  of  change  is  localized;  and 

o  possess  a  software  architecture  that  is  consistent  with  the  architectural 
framework  described  in  the  DoD  Technical  Architecture  for  Information 
Management  (TAFIM),  and  is  depicted  notionally  as  four  layers  of  software. 

3.5.1  Object  Oriented  Development 

NASM  shall  be  developed  using  object  oriented  analysis,  design,  and  implementation. 
NASM  shall  provide  a  common  system  object  repository  facility  including  configuration 
control,  to  allow  USAF  wargaming  without  joint  or  multiple  service  participation.  The 
common  framework  shall  support  both  physically  local  and  wide  area  repository  support. 
To  the  users  of  the  object  repository  it  shall  appear  that  is  a  single  logical  repository. 


3.5.2  Software  Development  Environment 

A  software  development  support  environment  that  includes  automated  tools  and  or 
manual  processes  that  enhance  productivity  and  allow  for  the  ease  of 
developing/changing  the  application  software,  shall  be  employed.  A  distributed  software 
development  environment  shall  be  considered. 


3.5.3  Common  Services 

NASM  shall  provide  common  services  comprised  of  tools  and  reusable  shared  software 
components  for  use  by  service  objects  and  models.  Services  will  be  products  that  range 
from  low-level  system  utilities  to  higher-level  application,  such  as  database  management. 
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Common  services  will  be  comprised  of  components  which  meet  Government  and 
industry  standards  promoting  open  architecture  in  a  multiple  vendor  heterogeneous 
environment.  These  services  shall  include  such  components  as:  network  services, 
graphics,  security,  operating  systems,  documentation,  instrumentation,  system 
management,  distributed  computing  environment,  knowledge  servers,  and  other  services. 

NASM  shall  provide  utilities  and  tools  to  support  error  handling,  system  monitoring  and 
system  debugging.  The  tools  provided  shall  allow  the  messages  within  NASM  to  be 
displayed  in  an  human-readable  format. 

3.5.4  Human  Factors  Engineering 

3.5.4. 1  Technical  Controller  Displays 

The  design  of  the  displays  shall  be  based  upon  guidelines  compatible  with  industry 
standards.  The  NASM  user  displays  designs  shall  provide  ease  of  use  and  convenience  to 
the  technical  controllers.  On-line  help  shall  be  available. 

3.5.4.2  End  User  Displays 

NASM  shall  provide  severable  component  user  interface  definitions,  representing  real 
world  C2  (e.g.,  CTAPS),  simulator  and  simulated  entity  level  platform/systems,  operator 
consoles,  and  others  as  appropriate  to  the  simulation  user.  Severable  user  interface 
definitions  imply  user  interface  displays  are  not  hard-coded  and  possess  a  “natural” 
breakout  of  user  functionality. 


3.6  System  Behavior  and  Design  Characteristics 


3.6.1  Adaptability 

The  NASM  system  shall  be  developed  to  be  adaptable.  Adaptability  will  be  essential  for 
the  NASM  architecture,  since  it  must  support  not  only  the  current  Air  Force  simulation 
requirements  based  on  the  Air  Warfare  Simulation  (AWSIM)  but  newly  identified 
additional  operational  requirements,  educational  requirements,  and  future  simulation 
capabilities  not  yet  identified.  The  NASM  architecture  shall  also  be  adaptable  to  support 
for  rapid  introduction/insertions  of  advanced  technology  within  the  system.  The 
architecture  also  needs  to  allow  NASM  to  evolve  for  broader  applications,  such  as 
information  warfare,  and  to  be  tailored  to  site-specific  needs  (ranging  from  seminar 
training  though  major  exercises).  To  achieve  adaptability,  the  NASM  architecture  shall 
be  flexible,  extensible,  evolvable,  and  scaleable. 
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3.6.2  Flexibility,  Extensibility,  and  Evolvability,  and  Scaleability 

The  NASM  design  shall  accommodate  growth.  The  NASM  system  shall  be  designed  to 
accommodate  simulations  identified  by  future  user  communities  (e.g.,  analysis,  test  and 
evaluation). 

The  NASM  design  shall  have  the  ability  to  readily  accommodate  modifications  and 
additions  to  satisfy  the  evolving  requirements  in  both  the  NASM  architecture  and  the 
NASM  simulations. 

The  NASM  system  architecture  and  design  shall  have  the  flexibility  and  extensibility  to 
accommodate  changes  to  the  architecture  which  include  changes  to  the  architectural 
components. 

The  NASM  system  design  shall  be  scaleable  to  accommodate  the  ability  to  model 
thousands  of  entities  at  varying  levels  of  fidelity. 

Methods  to  ease  portability  of  the  models  to  a  new  environment  containing  hardware  and 
software  services  that  may  differ  from  the  original  implementation  shall  be  employed. 


3.6.3  Repeatability 

The  NASM  simulation  executions  shall  be  repeatable;  that  is,  if  the  same  simulation  runs 
twice  with  the  same  inputs  supplied  at  exactly  the  same  times,  including  seeds  for  random 
elements,  the  simulation  results  will  be  identical.. 


3.6.4  Causality 

NASM  shall  support  maintenance  of  causality  of  events.  The  maintenance  of  the 
causality  of  events  is  the  preservation  of  the  time  step  order  when  distributing  events 
between  simulations,  (i.e.,  events  received  by  two  or  more  simulations  will  receive  the 
events  in  the  same  relative  ordering)  and  no  event/data  will  be  delivered  in  the  past. 

3.6.5  Distributed  Computing 

The  “train  where  you  fight”  requirement  has  lead  NASM  to  be  scoped  as  a  distributed 
simulation  system  across  potentially  long  haul  disparate  geographical  areas.  Distributed 
computing  shall  apply  to  all  aspects  of  the  NASM  system,  not  just  to  the  execution  phase 
of  an  exercise.  Data  access  as  well  as  processing  shall  be  capable  of  being  distributed. 
Pre-exercise  planning  and  setup  shall  support  the  capability  for  the  training  staff  to  be 
located  at  different  physical  locations  and  on  different  equipment,  yet  capable  of 


-34- 


Version  7.3, 19  Mar 


96 

Draft  National  Air  &  Space  [Warfare]  Model  (NASM)  Technical  Requirements  Document 

coordinating  their  activities  (having  shared  access  to  the  same  information  in  a  controlled 
manner)  and  collaboratively  planning  an  exercise.  During  post-exercise  activities, 
different  individuals  shall  have  the  ability  to  access  the  raw  exercise  results  for  analysis 
and  after  action  review,  and  that  access  shall  be  supported  from  widely  separated 
locations.  The  NASM  development  environment  shall  also  support  distributed  system 
development  and  integration. 

3.6.6  Interoperability 

NASM  shall  interoperate  with  those  systems  defined  in  sections  3.4.2,  3.4.3,  and  3.4.4. 
NASM  system  architecture  shall  be  designed  to  easily  accommodate  requirements  for 
interoperability  with  future  systems. 


3.6.7  Reliability  and  Availability 

NASM  shall  be  capable  of  operating  24  hours  per  day,  7  days  a  week.  NASM  shall  be 
capable  of  support  training  exercises  whose  duration  ranges  from  1  to  30  days,  24  hours 
per  day. 

NASM  shall  be  capable  or  restarting  an  exercise  from  the  point  of  failure  no  more  than 
one  hour  after  a  correction  from  a  system  failure. 


3.6.8  Maintainability  and  Supportability 

The  NASM  system  shall  be  maintainable  and  supportable.  Sufficient  data  shall  be 
developed  and  delivered  to  support  a  two  level  maintenance  concept:  organizational  and 
depot.  Each  level  shall  support  both  on-equipment  and  off-equipment  maintenance. 

NASM  shall  be  designed  and  developed  to  support  the  transition  from  the  current  air 
force  training  model(s). 


3.6.9  Training 

NASM  shall  be  designed  to  minimize  NASM  system  training  requirements  and  the  life 
cycle  costs  of  training.  Training  shall  be  provided  for  all  NASM  users  described  in 
section  3.1. 

No  more  than  12  hours  shall  be  required  to  train  new  technical  controllers  and  no  more 
than  6  hours  shall  be  required  to  train  end  user  (i.e.,  players). 
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Maximum  training  time  for  each  of  the  NASM  specific  external  interfaces  (i.e.,  Real 
world,  external  systems  (e.g.,  JSIMS,  WARSIM)  shall  be  no  more  than  2  hours  for 
familiarity  and  no  more  than  6  hours  for  proficiency. 

3.6.10  Performance 

NASM  shall  be  capable  of  supporting  an  exercise  with  variable  number  of  sides 
including:  5  services  from  10  nations  (5  services  per  nation)  in  coalition,  neutral  forces, 
suspect,  and  opposing  forces. 

TBD  -  Maximum  size  of  scenario,  including  maximum  number  of  mission  per  exercise, 
maximum  number  of  individual  assets  (including  radars,  maximum  number  of  end  users, 
exercise  duration.  Include  requirements  for  balanced  scenarios. 


3.6.11  Security  and  Trust 

NASM  shall  provide  for  a  minimum  of  two  concurrent  levels  of  classifications,  ranging 
from  unclassified  to  top-secret  (including  special  compartmented  categories).  Security 
labeling  and  control  of  data  shall  be  based  upon  the  security  classification  levels 
(Unclassified,  Confidential,  Secret,  and  Top  Secret,  etc.  as  well  as  caveats  (NOFORN, 
NATO  Releasable,  Releasable  to  UK/CAN.  WNINTEL,  etc.)  Support  systems  shall 
require  protection  from  unauthorized  access.  Systems  shall  require  protection  from 
computer  viruses.  To  the  extent  practical,  NASM  software  shall  be  unclassified. 
Software  modules  that  contain  classified  data  and  algorithms  shall  be  written  and 
integrated  with  the  remainder  of  the  NASM  software  in  a  manner  that  permits  the 
remainder  of  the  software  to  used,  stored,  and  generally  treated  as  unclassified.  NASM 
shall  be  readily  integrated  into  a  site’s  physical  facility  without  requiring  any  additional 
physical  security  enhancements  over  those  presently  required  for  AWSIM.  NASM 
resident  data  shall  be  classified  no  higher  than  secret .  Top  secret  and  compartmented 
information  shall  be  sanitized  to  secret  prior  to  use  within  NASM. 


3.6.12  Software  Languages 

NASM  shall  be  developed  using  Ada  to  the  maximum  extent  possible. 

Considerations  that  may  affect  software  language  choices  are  backward  reuse, 
commercial  or  government  standards,  and  the  use  of  a  particular  development 
methodology,  e.g.,  object  oriented.  All  software  languages  used  to  develop  NASM  shall 
be  supportable  across  heterogeneous  platforms.  Proprietary  software  languages  shall  not 
be  used. 
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4.  Not  Applicable 

5.  Not  Applicable 

6.  Notes 

6.1  Aggregation/Deaggregation 

To  support  the  capabilities  required  for  aggregation  and  deaggregation  the  NASM 

architecture  must  provide  several  key  capabilities. 

o  Architecture  must  support  the  dynamic  creation  and  removal  of  entities 
during  the  exercise  when  entities  are  deaggregated  and  aggregated.  This 
includes  aspects  of  entity  identification,  initialization  from  aggregate  data 
upon  deaggregation,  data  collection  among  others.  Architecture  must  also 
support  the  reaggregation  of  entities  in  the  exercise.  Reaggregation  would 
aggregate  component  entities  together  that  were  once  an  aggregate  entity. 

deaggregatedeaggregationdeaggregationdeaggregationdeaggregation 

o  Architecture  must  be  able  to  deaggregate  entities  into  sub-entities  on  a 
distributed  network.  De-aggregating  an  Air  Command  into  it  sub-entities 
may  result  in  the  formation  of  numerous  entities.  These  entities  may  need 
to  be  distributed  across  nodes  in  the  computer  network  to  satisfy  run-time 
requirements  for  the  exercise.  This  is  also  true  for  aggregating  entities 
together.  These  entities  that  will  form  the  aggregation  may  be  located  on 
different  nodes. 

o  Architecture  must  provide  a  consistent  mechanism  that  will  handle  the 
deaggregation  and  aggregation  of  entities  within  the  exercise.  Aggregate 
objects  must  supply  information  to  the  architecture  related  to  the  aggregate 
entity,  such  as  overall  size,  number  on  entities  within  the  aggregate, 
information  on  entity  layout  upon  being  deaggregated  to  allow  for  correct 
laydown  of  disaggregated  entities. 

o  The  architecture  must  have  the  capability  to  represent  entities  both  at  the 
aggregated  level  and  at  the  deaggregated  level  (i.e.,  NASM  entities  may  be 
grouped/ungrouped  into/out  of  more  aggregated  entities  and  NASM 
entities  may  internally  have  multiple  levels  of  resolution).  One  entity  may 
be  close  enough  to  an  aggregated  entity  that  this  entity  must  be 
deaggregated  so  that  its  sub-entities  are  visible  to  this  other  entity. 
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However,  there  may  be  another  entity  in  the  exercise  that  should  not  be 
able  to  view  the  sub-entities  of  this  aggregated  entity  and  thus  the 
aggregated  entity  should  remain  aggregated  with  respect  to  this  second 
entity. 


6.2  External  Interfaces 

The  dimensions  of  the  problems  of  interfacing  to  real  world  systems  and  to  external,  non- 
HLA  simulations  are  very  similar.  A  typical  solution  to  both  problems  is  to  define  an 
interface  object  which  will  convert  data  between  the  format  used  by  the  external 
simulation  or  live  system  and  the  internal  data  format  used  by  NASM.  (The  DMSO- 
sponsored  Modular  Reconfigurable  C4I  Interface  (MRCI)  is  an  example  of  a  generic 
interface  object).  This  will  include  scaling,  byte  swapping,  floating  point  conversion,  and 
coordinate  system  transformation,  as  needed.  Both  synchronous  and  asynchronous  data 
must  be  handled.  One  way  to  accomplish  this  would  be  through  the  use  of  data 
interchange  &  transformation  agents.  To  facilitate  development  of  data  interchange  & 
transformation  mechanisms  and  their  configuration  into  simulations,  the  NASM 
architecture  must  provide  the  following  features: 

o  A  standard  Object  Model  Template  for  data  interchange  &  transformation  of 
objects  and  their  attributes; 

o  "Mix  and  match"  communications  services  which  can  be  configured  to  handle  the 
required  interfaces  to  external  simulations,  ranging  from  satellite  link  to  TCP/IP 
to  serial  data  link; 

o  A  standard  API  for  communications  services,  so  that  new  communications 
protocols  may  be  added  to  NASM  easily 

o  Isolation  of  a  physical  system  translation  layer  for  each  external  system  instance 
to  afford  maximum  reuse  between  the  API  and  the  system  specific  layer. 

o  A  language  for  specification  of  formats,  timing,  and  conversion  requirements  of 
data  interchange,  and  associated  tools  for  rapid  input  and  maintenance  of  interface 
specifications. 

6.3  Repeatability 

When  interfacing  many  systems  into  a  working  whole,  it  is  necessary  to  decide  whether 
the  simulation  must  be  repeatable.  Repeatability  means  that  the  if  the  same  simulation  is 
run  twice  with  the  same  inputs  supplied  at  exactly  the  same  times,  including  seeds  for 
random  elements,  it  will  produce  exactly  the  same  outputs.  In  general,  low  level 
simulations  such  as  tactical  simulations  and  engineering  analysis  are  more  likely  to 
require  repeatability  than  higher  order  simulations.  If  the  simulation  includes  human 
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input,  it  may  be  impossible  to  reproduce  the  inputs  exactly,  but  repeatability  may  still  be 
required  for  the  computer-generated  portions  of  the  simulation. 

Repeatability  is  affected  by  the  synchronization  methods  used  by  the  simulations.  A 
simulation  can  only  guarantee  repeatability  when  a  coordinated  time  synchronization 
method  is  chosen,  meaning  that  all  nodes  must  indicate  their  readiness  to  advance  the 
simulation  time  before  time  is  advanced  for  all.  Scaled  real  time  synchronization  does 
not  require  agreement,  so  repeatability  becomes  the  responsibility  of  the  modeller, 
requiring  careful  analysis  of  the  average  and  worst-case  response  times  for  all  elements  of 
the  simulation. 

6.4  Architectural  Considerations 

The  architecture  that  exhibits  these  characteristics  needs  the  following  features: 

a)  The  architecture  itself  must  be  comprised  of  modular,  obiect-based  components.  Such 
a  design  inherently  fosters  data  encapsulation  and  well-defined  interfaces. 

b)  Architectural  objects  must  interact  with  each  other  and  with  modeling  objects  during 
execution  of  an  exercise  through  a  potentially  distributed,  location-transparent,  well- 
defined  Application  Program  Interface  (APD.  This  feature  is  critical  to  support  the 
interchange  of  live,  virtual,  or  constructive  simulations  for  the  same  entity. 

cl  The  architecture  must  treat  all  model  objects  as  "black  boxes",  interacting  only  through 
the  architecture  API.  There  can  be  no  specialized  "god's-eye"  understanding  coded  into 
the  architecture  of  the  nature  of  the  models,  as  has  been  done  with  traditional  simulation 
executives. 

dl  The  services  provided  by  the  architecture  should  be  organized  into  layers  or  levels, 
ranging  from  "kernel"  to  higher-level  services  such  as  interaction  resolution  managers. 
"Kernel"  services  should  be  restricted  to  primitive  operations  such  as  object-object 
distributed  communication,  event  scheduling  and  timing,  data  access,  and  message 
logging,  which  are  basic  to  a  simulation.  Higher  level  services  are  more  likely  to  require 
tailoring  for  a  specific  simulation.  Well-defined  interfaces  will  be  required  between  each 
layer  to  allow  for  replacement. 

e)  A  well-defined,  generic  API  will  be  needed  for  tools,  executing  as  standalone 
programs,  to  execute  within  the  architecture  framework.  This  API  should  be 
conceptually  like  that  specified  in  the  OMG's  CORBA  specification. 

An  architecture  with  these  characteristics  will  exhibit  both  flexibility  and  extensibility 
because  it  will  be  easier  to  replace  any  given  architecture  component,  to  incorporate  new 
tools,  to  reconfigure  the  distribution  network,  and  to  support  a  variety  of  different  models 
and  simulation  applications.  Adjusting  the  scale  of  execution  will  be  a  matter  of 
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configuring  a  network  with  adequate  resources  and  possibly  selecting  specific  versions  of 
standard  services  appropriate  to  the  level.  This  results  from  the  fact  the  architecture  is 
inherently  distributed,  that  services  can  be  added  and  replaced,  and  that  there  is  no  model- 
specific  knowledge  embedded  in  the  architecture.  Interchanging  live,  virtual,  or 
constructive  simulations  for  the  same  entity  is  made  possible  by  the  use  of  an  interface 
object  that  maintains  the  same  standard  interface  to  the  rest  of  the  simulation  regardless 
of  what  provides  the  entity's  functionality. 

6.5  Distributed  Computing 

During  the  execution  of  the  exercise  distributed  computing  will  be  important  for  a 
number  of  reasons.  First,  the  very  nature  of  the  exercise  itself  often  requires  the 
participants  to  be  at  their  separate  locations  where  they  would  normally  carry  out  their 
roles  and  using  their  normal  equipment.  This  includes  not  only  the  trainees,  but  the  game 
controllers  or  instructors  as  well.  Second,  for  the  exercise  to  include  live  or  virtual 
components  whose  physical  locations  are  fixed,  there  must  be  communication  across  a 
distribution  network.  Third,  those  simulated  components  of  an  exercise  which  are  legacy 
systems  are  likely  to  be  platform-specific  and  hosted  at  a  particular  physical  site.  Finally, 
there  may  be  a  need  for  distributed  processing  in  order  to  achieve  the  required  throughput 
from  the  various  simulated  components,  either  because  of  their  sheer  numbers  or  because 
of  the  level  of  detail  of  the  simulation.  A  NASM  simulation,  in  addition  to  being 
distributed  within  itself,  must  also  interact  with  other  simulations  across  a  distributed 
network  as  part  of  a  High  Level  Architecture  (HLA)  federation. 

The  architecture  that  supports  these  capabilities  would  need  the  following  features: 

a)  A  mechanism  for  distributed  concurrent  shared  data  access. .  All  data  access  by 
simulation  or  architecture  entities  would  have  to  be  through  this  distributed  data 
mechanism  to  guarantee  transparency  of  data  physical  location  and  maximum  flexibility 
in  system  configuration. 

bt  Transparent  built-in  distribution  of  all  interactions  between  entities  in  the  system, 
whether  simulation  or  architectural.  There  must  be  no  assumptions  embedded  in  either 
the  modeled  objects  or  the  architecture  about  physical  locations  or  whether  entities  are  on 
the  same  system  or  not.  Ideally,  all  interactions  should  follow  a  paradigm  similar  to  that 
described  in  the  Object  Management  Group's  (OMG's)  Common  Object  Request  Broker 
Architecture  (CORBA).  Following  this  model,  entities  will  use  the  same  interface  to 
interact  whether  their  location  is  local  or  remote,  and  the  NASM  architecture  will  handle 
determining  the  location,  passing  distributed  messages,  and  any  synchronization  issues. 
Ideally,  the  NASM  architecture  will  make  use  of  a  commercially  available  infrastructure 
software  system  to  provide  this  capability. 

c)  No  for  at  least  tightly  isolated!  system  dependencies.  System  dependency  has  been  a 
traditional  drawback  to  distributed  processing.  However,  the  NASM  architecture  must 
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not  only  operate  over  a  variety  of  hardware  platforms,  but  must  be  readily  adaptable  to 
new  hardware  which  does  not  yet  even  exist.  The  physical  network  configuration  will 
likely  differ  from  one  NASM  session  to  another,  and  may  even  change  during  the 
execution  of  a  NASM  exercise.  Whether  the  nodes  are  connected  by  a  Local  Area 
Network  (LAN)  or  Wide  Area  Network  (WAN)  should  be  transparent  to  the  architecture. 
Likewise  whether  a  "best  effort"  or  "guaranteed  receipt"  protocol  is  used  must  be  readily 
altered  to  suit  the  particular  circumstances.  Commercial  ORBs  may  also  address  this 
capability. 

d)  Flexible,  user-friendly  configurability  to  the  available  hardware.  A  "user"  -  meaning  in 
this  case,  an  exercise  controller  or  system  support  person  -  should  be  able  to  specify  what 
will  be  distributed  and  how  through  a  user-friendly,  interactive  Graphical  User  Interface 
(GUI).  Network  configuration  should  not  require  changes  to  the  architecture  software  or 
use  of  obscure  system  files.  Some  commercial  ORBs  may  provide  a  preliminary  version 
of  this  capability. 

e)  A  means  to  predict  and  monitor  the  performance  of  a  particular  exercise  configuration. 
This  should  include  a  modeling  tool  that  allows  a  system  support  person  to  specify  not 
only  the  hardware  configuration  but  also  the  software  distribution  and  to  generate 
projected  performance  statistics  for  a  given  configuration.  The  software  distribution 
refers  to  the  location  and  grouping  of  software  objects.  Performance  predictions  would 
be  based  on  some  description  of  the  predicted  interactions  between  objects  and  statistical 
information  about  the  performance  of  each  object.  Commercial  tools  to  predict 
performance  of  the  hardware  components  of  a  system  are  available  now.  Analysis  of  the 
software  components  will  have  to  be  developed. 

Some  of  the  distributed  computing  issues  to  be  addressed  by  NASM  include  portability 
and  the  heterogeneous  nature  of  the  distributed  components,  issues  impacting  network 
performance,  and  compliance  with  an  HLA  compliant  Runtime  Infrastructure  (RTI). 
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GLOSSARY 

Aggregate  -  To  combine  multiple  entity  representations  into  a  single  entity 
representation,  with  the  aggregate  providing  the  correct  behavior  representation.  A 
classic  example  is  that  of  two  individual  friendly  aircraft  which,  even  in  close  proximity, 
behave  significantly  different  than  a  coordinated  flight  of  two  aircraft.  Aggregation  can 
also  apply  to  effects  (e.g.,  Electronic  Warfare)  and  types  of  representations  other  than 
force  representations.  Aggregation:  The  ability  to  group  entities  while  preserving  the 
effects  of  entity  behavior  and  interaction  while  grouped. 

Constructive  Model  or  Simulation  -  A  form  of  simulation,  which  for  the  training  domain 
are  commonly  called  wargames,  that  involves  software  representation  of  two  or  more 
opposing  forces,  using  rules,  data,  and  procedures  designed  to  depict  an  actual  or  real  like 
situation. 

Deaggregate:  To  create  multiple  entities  from  an  aggregated  entity,  the  entities  contained 
within  the  aggregated  entity  to  be  seen  as  individual  entities. 

Hot  Wash  -  a  review  meeting  which  is  held  concurrent  with  or  immediately  following  a 
session  of  training  (an  exercise)  to  summarize  initial  impressions  and  lessons  learned. 

Joint  Synthetic  Battlespace  -  an  operationally  realistic,  distributed,  simulated  mission 
space  that  includes  a  synthetic  environment,  force  representations,  and  behavioral 
representations. 

Live  Simulation  -  A  simulation  involving  real  people  operating  real  systems.  In  the  case 
of  NASM  this  includes  the  use  of  real  world  C4I  by  simulation  participants. 

Mission  Space  -  Mission  space  refers  to  the  entities,  actions,  and  interaction  that  must  be 
represented  to  produce  credible  simulations  of  the  specific  mission  area  being  addressed. 
Mission  space  includes  all  elements  which  support  the  simulation  and  which  are  required 
to  achieve  the  desired  goals  and  objectives.  The  mission  space  is  comprised  of  force, 
behavior,  and  environmental  representations. 

Model  -  (1)  A  representation  (executable  or  not)  of  real  things  or  events,  (e.g.  terrain,  air, 
space  land,  sea)  (2).  A  physical,  mathematical,  or  otherwise  logical  representation  of  a 
system,  entity,  phenomenon,  or  process. 

Models  -  a  group  or  combination  of  the  models  (e.g.,  synthetic  environment ) 

Scenario  -  (1)  Description  of  an  exercise  (initial  condition  in  military  terms).  It  is  part  of 
the  session  database  which  configures  the  units  and  platforms  and  places  them  in  specific 
locations  with  specific  missions.  (2)  An  initial  set  of  conditions  and  time  lines  for 
significant  events  imposed  on  trainees  or  systems  to  achieve  exercise  objectives. 

Simulation  -  (1)  A  model  that  behaves  or  operates  like  a  given  system  when  provided  a 
set  of  controlled  inputs.  (2)  The  process  of  developing  or  using  a  model  as  in  (1).  (3) 
An  element  of  a  special  kind  of  model  that  represents  at  least  some  key  internal  elements 
of  a  system  and  describes  how  those  elements  interact  over  time. 
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Simulation  Entity:  An  element  of  the  mission  space  that  is  created  and  controlled  by  a 
simulation.  Each  entity  may  be  implemented  in  software  by  one  or  more  objects  or 
modules.  Represented  entities  range  in  size  from  subcomponents  to  aggregated  units. 
Entities  can  be  comprised  of  other  entities.  It  is  possible  that  a  simulation  application 
may  be  controlling  more  than  one  simulation  entity.  An  entity  in  terms  of  NASM  is  any 
thing  or  any  group  of  things  which  may  be  modeled  discretely  (e.g.,  could  range  from  a 
tank  through  a  Corps). 

Simulation  Exercise  -  Consists  of  one  or  more  interacting  simulation  applications. 
Simulations  participating  utilize  correlated  representation  of  the  synthetic  environment  in 
which  they  operate.  NASM  will  be  composed  of  simulations  components  instanced  for  a 
particular  exercise. 

Simulation  System  -  a  group  of  simulations  packaged  with  ancillary  functions  (i.e., 
terrain  database,  thereat  database,  engagement  database)  that  may  interface  to  external 
systems  (e.g.,  NASM). 

Simulator-  (1)  A  special  case  of  virtual  simulation  that  provides  an  encapsulated  virtual 
environment  for  interfacing  with  the  simulation  system.  (2)  A  device,  computer 
program,  or  system  that  performs  simulations.  (3)  For  training  a  device  which  duplicates 
the  essential  features  of  a  task  simulation  and  provides  for  direct  practice.  (4)  A  physical 
model  or  simulation  or  a  weapon  system,  set  of  weapon  systems,  or  a  piece  of  equipment 
which  represent  some  major  aspects  of  the  equipment’s  operation. 

Virtual  simulation  -  A  simulation  involving  real  people  operating  simulated  systems. 
Virtual  simulations  inject  WITL  in  a  central  role  by  exercising  motor  control  skills, 
decision  skills,  or  communication  skills.  Form  of  a  simulation  in  which  entities  exist  in 
effect  or  in  essence,  although  not  in  actual  form.  Virtual  simulations  typically  represent  a 
single  platform  entity. 
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IOC/FOC  FUNCTIONAL  DESCRIPTION 

The  NASM  IOC  system  shall: 

o  shall  support  at  a  minimum  representations  included  in  the  re-engineered 
version  of  AWSIM;  (Details  regarding  functionality  related  to  re-engineered 
AWSIM  can  be  found  in  the  AWSIM/R  System  Specification.) 

o  provide  a  complete  distributed,  discrete  event,  constructive  simulation  system 
that  supports  Air  Force  and  joint  battlestaff  training  for  all  aerospace  missions; 

o  provides  all  air  and  space  models  necessary  to  support  the  USAF  component 
ofJSIMS; 

o  provide  a  complete  standalone  training  capability  to  train  the  battlestaff; 
including  pre-exercise,  exercise,  and  post-exercise  capabilities. 

o  interface  to  the  other  simulation  systems  in  order  to  satisfy  the  joint  training 
requirements; 

o  develop  and  implement  missions  (e.g.,  aerospace  mission,  MOOTW) 
necessary  to  satisfy  the  joint  training  requirements. 

o  interface  to  the  following  real  world  interfaces:  TBMCS,  C2IPS,  TADILs, 
and  TIBS. 

With  respect  to  the  capabilities  described  in  section  3. 2.2.2  Aggregation  and 
Deaggregation  and  3. 2.2.3  Behavioral  Representation  (semi-automated  forces  and 
computer  generated  forces),  partial  capability  sufficient  enough  to  support  battlestaff 
training  shall  be  provided  within  the  NASM  IOC  system  reducing  at  a  minimum  by  one 
third  the  resources  required  to  perform  an  exercise  (both  technical  controllers  &  role- 
players). 

The  NASM  IOC  and  subsequent  releases  shall  be  delivered  and  installed  at  the  following 
four  sites:  WPC,  BTS,  JWFC,  and  Air  University. 

The  releases  post  IOC  shall  evolve  the  NASM  system  to  satisfy  all  remaining  additional 
external  simulation  systems  and  real  world  interfaces.  The  Post  IOC  releases  shall  also 
address  additional  eductional  requirements.  The  FOC  system  shall  also  satisfy  the 
additional  mission  requirements  for  MOOTW,  information  warfare  and  special  operations 
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not  included  in  previous  releases.  All  of  the  requirements  described  in  this  TRD  shall  be 
satisfied  by  FOC. 
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ACRONYM  LIST 


AAM 

AAR 

ACO 

ADANS 

ADS 

AFM 

AFMC 

AFMSS 

AFWI 

AFR 


Air  to  Air  Missile 
After  Action  Review 

Air  Coordination  Order;  Airspace  Control  Order 

AMC  Deployment  Analysis  System 

Advanced  Distributed  Simulation 

Air  Force  Manual 

Air  Force  Materiel  Command 

Air  Force  Mission  Support  System 

Air  Force  Wargaming  Institute 

Air  Force  Regulation 


AMC 

AMG 

AMRAAM 

AOC 

ASM 

ATO 

ATOCONF 

AWSIM 


Air  Mobility  Command 

Architecture  Management  Group 

Advanced  Medium  Range  Air  to  Air  Missile 

Air  Operations  Center 

Air  to  Surface  Missile 

Air  Tasking  Order 

Air  Tasking  Order/Confirmation 

Air  Warfare  Simulation 


BDA  Battle  Damage  Assessment 

BTS  Battlestaff  Training  School 

BVR  Beyond  Visual  Range 

Q?-  Command  and  Control 

C2IPS  Command  and  Control  Information  Processing  System 

C^I  Command,  Control,  Communications,  and  Intelligence 

C4I  Command,  Control,  Communications,  Computers,  and  Intelligence 

CAS  Close  Air  Support 

CGF  Computer  Generated  Forces 

CIS  Combat  Intelligence  System 

CMARP  Combined  Mating  and  Rating  Planning  System 

CMMS  Conceptual  Model  of  the  Mission  Space 

COMPUSEC  Communications  Security  and  Computer  Security 

COMSEC  Communications  Security 

COTS  Commercial  off-the-shelf 

CTAPS  Contingency  Theater  Automated  Planning  System 


DCA  Defensive  Counter  Air 

DIA  Defense  Intelligence  Agency 

DIS  Distributed  Interactive  Simulation 

DMPI  Desired  Mean  Point  of  Impact 

DMS  Digital  Mapping  System 

DMSO  Defense  Modelling  and  Simulation  Office 

DoD  Department  of  Defense 


ESC  Electronic  Systems  Center 
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ESR  Equipment  Status  Reporting 

FID  Foreign  Internal  Defense 

FOC  Full  Operational  Capability 

F  OM  F  ederation  Obj  ect  Model 

GCCS  Global  Command  and  Control  System 

GDSS  Global  Decision  Support  System 

GOTS  Government  off-the-shelf 

HIMAD  High  and  Medium  Range  Air  Defense 
HLA  High  Level  Architecture 

HQ  Headquarters 

ICD  Interface  Control  Document 

INFOSEC  Information  Security 

IOC  Integrated  Operational  Capability 

JCMT  Joint  Collection  Management  Tool 

JDISS  Joint  Deployable  Intelligence  Support  System 

JECEWSI  Joint  Electronic  Combat  Warfare  Simulation 
JFACC  Joint  Forces  Air  Component  Commander 

JSIMS  Joint  Simulation  System 

MAP  Master  Attack  Plan 

MDC  Maintenance  Data  Collection 

MISREP  Mission  Report 

MOOTW  Military  Operations  Other  Than  War 

MRC  Major  Regional  Contingency 

MSFD  Multi-Spectral  Force  Deployment 

NASM  National  Air  and  Space  (Warfare)  Model 

NATO  North  Atlantic  Treaty  Organization 

NATSIM  National  Intelligence  Simulation 

NDI  Non-developmental  item 

OOB  Order  Of  Battle 

OCA  Offensive  Counter  Air 

OMA  Object  Management  Architecture 

OMG  Object  Management  Group 

OPFOR  Opposing  Forces 

PGM  Precision  Guided  Munitions 

PSYOP  Psychological  Operations 

R&M  Reliability  and  maintainability 

RTI  Run  Time  Infrastructure 

SAFOR  Semi  Automated  Forces 

SAM  Surface-to-Air  Missile 

SE  AD  Suppression  of  Enemy  Air  Defenses 

SEI  Software  Engineering  Institute 
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SHORAD 

SOF 

SOM 

SPT 

SSF 

STD 

STOMPS 


Short  Range  Air  Defense 
Special  Operations  Forces 
Simulation  Object  Model 
Self  Protection  Jammer 
Software  Support  Facility 
Standard 

Standalone  Tactical  Operational  Message  Processing  System  (STOMPS) 


TADIL 

TBD 

TBMCS 

TELS 

TEP 

TIB 

TPFDD 

TRAP 

TRD 

TRE 


Tactical  Data  Information  Link 
To  be  determined 

Theater  Battle  Management  Core  Systems 
Transportable  Erector  Launcher  System 
Tactical  Elint  Processor 
Tactical  Information  Broadcast  System 
Time-Phased  Force  and  Deployment  Data 
TRE  and  Related  Applications 
Technical  Requirements  Document 
Tactical  Receive  Equipment 


USAF  United  States  Air  Force 

U SMTF  U.  S .  Message  T ext  F ormat 


WAN 

WARSIM 

WCCS 

WITL 

woe 

WPC 

WVR 


Wide  Area  Network 

Warfighter’s  Simulation 

Wing  Command  and  Control  System 

Warfighter-in-the-loop 

Wing  Operations  Center 

Warrior  Preparation  Center 

Within  Visual  Range 
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